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PREFACE 


This  document  includes  the  minor  enhancements  the  Logistics  Management 
Institute  has  made  to  M-SPARE  since  the  previous  model  doc\unentation  in  August 
1992.  The  enhancements  fall  into  two  basic  categories:  Hrst,  those  that  expand  the 
M-SPARE  forecasting  capability  include  repair  budgets,  ground-storage  packing 
requirements,  and  preventive  maintenance  spares  estimates;  second,  those  that 
make  M-SPARE  more  responsive  to  user  needs  and  let  the  user  limit  the  output 
reports  M-SPARE  generates,  use  either  current  or  constant  year  dollars,  select  spares 
based  upon  the  orbital  replacement  unit’s  procurement  lead  time,  or  use  two  types  of 
probability-of-sufliciency  estimates. 
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Executive  Summary 

ESTIMATING  SPARES  REQUIREMENTS 
FOR  SPACE  STATION  FREEDOM 

Using  the  M-SPARE  Model 


Space  Station  Freedom  (SSF)  will  be  a  manned  research  laboratory  designed  by 
NASA  to  orbit  200  miles  above  the  Earth  for  30  years.  To  ensure  the  safety  of  its 
crew  and  the  success  of  its  missions,  the  station  will  need  additional  parts  (spares)  to 
replace  failed  equipment.  Because  spares  are  expensive  and  SSF  budgets 
constrained,  NASA  needed  a  method  to  determine  the  optimal  spares  inventory  for  a 
speciHed  cost. 

The  Multiple  Spares  Prioritization  and  Availability  to  Resource  Evaluation 
(M-SPARE)  model  provides  NASA  that  capability.  M-SPARE  implements  a  method 
that  considers  the  unique  characteristics  of  SSF,  applies  across  all  SSF  organi¬ 
zational  levels,  and  ensures  the  best  station  performance  for  any  specified  level  of 
investment.  M-SPARE  has  evolved  significantly  over  its  4-year  life  and  now 
addresses  most  SSF  spares  issues.  NASA  is  currently  using  M-SPARE  to  answer 
three  basic  questions  concerning  SSF: 

•  What  spares  does  it  need? 

•  When  does  it  need  them? 

•  How  much  will  they  cost? 

This  guide  describes  the  M-SPARE  methodology,  products,  capabilities,  and 
operations  necessary  to  answer  those  questions. 

Methodology  —  The  core  of  M-SPARE  is  its  selection  methodology  that  links 
station  performance  to  spares  resource  requirements.  Station  performance  (we  term 
it  availability)  is  defined  as  the  probability  that  no  critical  system  becomes 
inoperative  over  the  resupply  cycle  (time  interval  between  shuttle  flights)  for  lack  of 
an  orbital  replaceable  unit  (ORU)  spare.  The  annual  spares  resource  requirement 
can  be  a  single  resource  such  as  budget  dollars,  weight  the  shuttle  can  carry,  station 
storage  volume,  or  it  can  be  a  combination  of  resources.  M-SPARE  is  based  on  a 


vii 


NS101R2/JULY  93 


marginal-analysis  approach.  Spares  are  ranked  in  order  of  decreasing  benefit  per 
cost  (essentially  the  improvement  provided  to  station  availability  per  unit  resource) 
and  added,  in  that  order,  to  the  inventory  until  a  target  resource  expenditure  or 
station  availability  is  reached.  Besides  resources,  the  model  also  considers  the  ORU’s 
failure  rate,  frequency  of  shuttle  resupply,  repair  time,  procurement  lead  time,  and 
assembly  sequence. 

Products  —  M-SPARE  develops  three  key  products  over  a  specified  period  of 
the  station’s  life.  First,  it  specifies  the  entire  range  (a  plotted  curve)  of  how  SSF’s 
availability  changes  as  annual  spares  resource  expenditures  change.  Every  point  on 
the  curve  corresponds  to  an  optimal  spares  mix  that  maximizes  station  availability. 
Second,  the  model  develops  a  list  of  required  spares  by  year  based  upon  a  user- 
specified  station  availability  target  or  resource  constraints.  Finally,  the  model 
converts  spares  requirements  over  a  period  of  station  life  to  current  funding 
estimates  for  the  next  9  fiscal  years. 

Other  Capabilities  —  To  conserve  weight  and  volume,  the  model  optimizes  the 
spares  storage  location  so  that  only  the  most  vital  spares  are  stored  on  orbit.  To 
resolve  conflicting  resource  constraints,  the  model  develops  a  range  of  tradeoff 
options  enabling  users  to  determine  a  balanced  solution.  To  help  produce  complete 
budget  estimates,  the  model  estimates  spares  requirements  for  all  types  of  ORUs 
(critical  and  noncritical).  To  address  additional  spares-related  costs,  the  model  also 
estimates  ORU  repair  budgets. 

Operations  —  M-SPARE  operates  on  a  personal  computer,  making  the  model 
accessible  to  SSF  users.  It  contains  a  menu-driven  interface  so  that  users  can  easily 
prepare  inputs,  run  the  model,  and  analyze  results.  The  model’s  data  requirements 
are  based  upon  existing  user  data  base  information  so  that  the  model  is  responsive  to 
current  conditions.  It  is  an  analytic  model  that  generates  solutions  in  minutes. 

With  the  use  of  M-SPARE,  NASA  obtains  three  important  benefits: 

•  A  comprehensive  approach  that  helps  to  ensure  station  spares  are  available 
when  needed 

•  A  consistent  approach  for  the  many  organizations  that  are  involved  with 
SSF 

•  A  defensible  approach  that  links  spares  budgets  to  station  availability,  the 
ultimate  program  goal. 
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CHAPTER  1 


INTRODUCTION 


Space  Station  Freedom  (SSF)  will  be  a  manned  orbital  research  laboratory  with 
a  planned  life  cycle  of  30  years.  The  station  will  orbit  200  miles  above  Earth,  and  its 
only  life  line  to  the  planet  will  be  a  few  shuttle  resupply  flights  each  year.  Although 
the  original  station  components  are  highly  reliable,  spares  are  necessary  to  replace 
the  possible  component  failures  that  astronauts  cannot  repair.  Thus,  spares  are 
necessary  to  ensure  maximum  station  performance  and  minimal  crew  risk.  NASA 
asked  LMI  to  develop  a  model  to  answer  three  basic  questions  about  SSF; 

•  What  spares  are  needed? 

•  When  are  they  needed? 

•  How  much  will  they  cost? 

In  this  guide,  we  present  a  methodology  that  prioritizes  spares  selection  as  the 
station  is  assembled  and  operated.  Optimal  spares  requirements  are  converted  into 
funding  requirements,  which  drive  NASA  spares  budgets. 

Over  the  past  4  years,  we  developed  a  model  to  address  most  of  SSFs  reparable 
spares  issues.  It  is  called  the  Multiple  Spares  Prioritization  and  Availability  to 
Resource  Evaluation  (M-SPARE)  model.  The  core  of  the  model  is  its  spares  selection 
methodology  that  links  station  performance  to  spares  resource  requirements.  Station 
performance  (what  we  term  availability)  is  defined  as  the  probability  that  no  critical 
system  becomes  inoperative  over  the  resupply  logistics  cycle  (the  interval  between 
shuttle  resupply  launches)  for  lack  of  an  orbital  replaceable  unit  (ORU)  spare.  The 
spares  resource  requirement  can  be  a  single  resource  (such  as  budget  dollars,  weight 
the  shuttle  can  carry,  or  station  storage  volume)  or  a  combination  of  resources. 

The  M-SPARE  model  is  based  on  a  marginal-analysis  approach.  Spares  are 
ranked  in  order  of  decreasing  benefit  per  cost  (essentially  the  improvement  provided 
to  station  availability  per  unit  resource)  t  and  added,  in  the  same  order,  to  the 


iPor  technical  reasons,  M-SPAREs  actually  considers  the  logarithm  of  the  increase  in 
availability.  See  Appendix  A. 
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inventory  until  a  target  resource  expenditure  or  station  availability  is  reached. 
Besides  resources,  the  model  also  considers  the  ORU’s  failure  rate,  frequency  of 
shuttle  resupply,  repair  time,  procurement  time,  and  assembly  sequence. 

'T"  e  M-SPARE  model  develops  three  key  products.  First,  it  specifies  how  SSF 
avalicibility  changes  as  resource  expenditures  change  (Figure  1-1).  Every  point  on 
the  plotted  curve  corresponds  to  an  optimal  spares  mix  that  maximizes  availability 
for  a  given  resource  level.  Second,  the  model  develops  a  list  of  required  spares  by  year 
based  upon  a  user-specified  station  availability  target  or  resource  target.  Finally,  the 
model  converts  spares  requirements  over  a  period  of  station  life  to  current  funding 
estimates  that  shape  NASA  spares  budgets  for  the  next  9  fiscal  years. 


Station 

availability 

(%) 


FIG.  1-1.  RESOURCE-VERSUS-STAHON-AVAI LABILITY  CURVE 
(Critical  on-orbit  ORUs) 

Model  operations  start  with  two  basic  inputs  —  annual  station  configurations 
and  annual  station  targets  (see  Figure  1-2).  The  SSF  configuration  specifies  the  ORU 
criticality  type,  population,  and  characteristics  such  as  failure  rates  and  ground 
repair  times.  The  SSF  targets  help  specify  the  size  of  the  required  spares  inventory. 
Users  can  specify  availability,  price,  weight,  or  volume  targets  or  any  target 
combination.  Given  those  inputs,  M-SPARE  automatically  determines  the  gross 
spares  requirement  for  successive  years  of  the  station’s  life  —  the  total  number  of 
spares  of  each  item  needed  in  the  inventory  to  reach  the  specified  target.  Next,  the 
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model  estimates  the  annual  difference,  by  item,  between  gross  requirements  and 
available  assets  (spares  procured  in  previous  years).  That  difference  is  the  net  spares 
requirement.  The  accumulation  of  each  item’s  net  spares  requirement  times  the  unit 
price  then  drives  the  estimates  for  the  budgets  in  the  fiscal  years  a  procurement  lead 
time  earlier.  We  chose  that  fiscal  year  format  so  that  M-SPARE  outputs  are 
consistent  with  the  SSF  general  budget  process.  [Note:  When  we  refer  to  budgets,  we 
really  mean  outlays  that  accrue  in  a  specific  fiscal  year  as  opposed  to  obligations  that 
can  be  spent  over  several  years.] 
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In  addition,  M-SPARE  has  the  following  capabilities: 

•  It  determines  the  optimal  storage  location  (on  orbit  or  ground)  for  each  type 
of  spare.  If  on-orbit  storage  is  not  available,  users  can  override  that 
optimization  and  specify  ground  storage  only. 

•  It  balances  conflicting  resource  constraints  such  as  spares  budget  dollars 
and  shuttle  weight  limitations. 

•  It  estimates  spares  weight  and  volume  projections  to  resupply  all  failures 
throughout  each  year. 

•  It  produces  a  combined  budget  for  all  types  of  ORUs  (e.g..  Criticality 
Codes  1,2,  and  3). 

•  It  constrains  spares  levels  to  a  specified  annual  budget. 

•  It  estimates  reparable  spares  requirements,  including  condemnations  (a 
broken  spare  that  can  no  longer  be  fixed). 

•  It  produces  supplementary  estimates  of  annual  repair  budgets  and  ground 
packing  requirements. 

•  It  estimates  spares  based  upon  ORU  failures  from  random  and  time- 
dependent  processes  (e.g.,  wear-related  failures  or  preventive  maintenance 
actions  that  usually  occur  when  an  ORU  is  a  certain  age). 

•  It  estimates  the  benefit  (availability  improvement  or  the  cost  savings)  of 
changing  the  resupply  frequency  or  using  common  ORUs  for  more  than  one 
application. 

•  It  generates  most  solut'<  ns  within  minutes  on  IBM-compatible  personal 
computers  (PCs). 

USERS  GUIDE  ORGANIZATION 

In  this  guide,  we  describe  the  M-SPARE  model  methodology,  why  that 
methodology  is  used,  and  the  algorithms  within  the  computer  code.  We  offer  further 
guidance  to  the  user  to  install  and  operate  the  model,  describe  the  model’s  data  inputs 
and  how  to  modify  them,  and  present  sample  data  outputs  and  what  they  mean.  In 
addition,  we  describe  how  to  modify  model  assumptions  to  perform  various  types  of 
analyses.  The  remainder  of  this  Chapter  and  oaapter  2  present  an  overview  of  the 
model  methodology  and  operation.  Chapters  3  and  4  concentrate  on  the  technical 
details  of  the  methodology.  The  remaining  chapters  present  details  on  how  to  use  the 
model.  The  following  paragraphs  describe  each  chapter  in  more  detail: 


•  Chapter  1  —  Introduction.  In  the  rest  of  this  chapter,  we  discuss  why  the 
station  needs  spares  and  present  simple  examples  to  illustrate  why  the 
M-SPARE  methodology  outperforms  a  more  traditional  sparing  approach. 
We  also  outline  the  overall  model  methodology. 

•  Chapter  2  —  Installation  and  Demonstration.  In  this  chapter,  we  discuss 
how  to  install  the  model  on  a  PC  and  guide  the  user  through  a  test  drive. 
That  whole  process  takes  about  10  minutes  and  gives  an  overview  of  the 
model’s  operation  and  capability.  We  also  discuss  the  model  user  interface 
that  helps  users  prepare  input,  operate  the  model,  and  analyze  results. 

•  Chapters  —  Spares  Prioritization  Overview.  In  this  chapter,  we  provide  an 
overview  of  the  spares  optimization  methodology  and  capabilities. 
Specifically,  we  discuss  station  availability,  the  optimal  spares  selection 
process,  and  resource  tradeoff  analyses. 

•  Chapter  4  —  Detailed  ORU  Multi-Echelon  Methodology.  In  this  chapter,  we 
present  the  details  of  the  ORU  multi-echelon  tradeoff,  the  basic  building 
block  of  the  spares  selection  process.  That  tradeoff  considers  a  host  of  factors 
such  as  on-orbit  failure  rates,  times  required  to  repair  or  replace  ORUs,  and 
shuttle  flight  frequency.  The  final  result  is  an  optimal  tradeoff  that  decides 
the  mix  of  spares  to  be  stored  on  orbit  and  on  the  ground  and  the  resulting 
station  availability. 

•  Chapters  —  Model  ORU  Input  Data.  This  chapter  discusses  the  input  data 
required  for  the  model  and  how  to  create  or  modify  those  data. 

•  Chapter  6  —  Model  Options.  This  chapter  discusses  the  procedure  for  setting 
basic  model  options  that  change  infrequently  such  as  the  element  launch 
schedule  or  the  budget  time  horizon. 

•  Chapter  7  —  Model  Operation  and  Analysis.  In  this  chapter,  we  discuss  the 
steps  required  to  run  the  model  and  the  different  modes  of  operation.  We 
also  discuss  the  types  of  analyses  —  estimating  spares  mixes,  using  multiple 
resources,  developing  resource  tradeoffs,  and  examining  alternative  solu¬ 
tions. 

•  Chapter  8  —  Model  Outputs.  This  chapter  presents  model  outputs  and 
describes  how  to  interpret  them.  The  model  produces  two  files.  One  is  a 
budget  file  that  summarizes  spsu'es  and  funding  requirements  over  time;  the 
other  is  a  detailed  output  file  that  focuses  on  displaying  pertinent  input, 
intermediate  results,  and  output  data  used  in  the  model. 
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•  Chapter  9  —  M -SPARE  Use  for  the  Program  Operating  Plan  (POP).  In  this 
chapter,  we  discuss  how  to  use  M-SPARE  for  its  ma^jor  purpose:  to  produce 
spares  and  funding  requirements  for  a  POP  cycle  (part  of  NASA’s  overall 
budget  process). 

•  Chapter  10  —  The  Wear  Preprocessor.  In  this  chapter,  we  discuss  how  the 
model  deals  with  ORUs  that  wear  out.  Besides  the  standard  random 
failures,  ORUs  may  also  exhibit  a  failure  mode  after  being  in  operation  for  a 
specific  period  of  time.  M-SPARE  uses  a  preprocessor  that  simulates  wear- 
out  and  random  failures  over  15  years  of  the  station’s  life.  The  preprocessor 
then  produces  a  time-dependent,  aggregate  failure  rate  that  M-SPARE  uses 
in  the  spares  prioritization. 

•  Appendix  A  —  Spares  Optimization  Proof.  This  appendix  presents  a 
mathematical  proof  for  the  model’s  optimization  methodology. 

•  Appendix  B  —  Repair  Budget:  Methods,  Assumptions,  and  Data.  The  repair 
budget  starts  where  the  spares  budget  leaves  o^.  That  is,  once  you  procure  a 
spare,  you  incur  additional  costs  if  the  spare  breaks  and  requires  repair.  In 
this  appendix,  we  describe  how  we  converted  historic  repair  data  from 
existing  NASA  systems  to  serve  as  the  foundation  of  the  M-SPARE  repair 
method  for  Space  Station  Freedom. 

•  Appendix  C  —  Glossary.  This  glossary  defines  the  acronyms  used  through¬ 
out  this  guide. 

WHY  DOES  THE  STATION  NEED  SPARES? 

A  basic  question  is  why  does  a  station  whose  components  fail  every  30  years  or 
more  on  average  need  spares?  That  is  especially  true  when  you  consider  that  even  if 
an  item  fails,  the  station  has  redundant  backup  systems  that  will  work  in  its  place. 
The  question  seems  reasonable  until  you  start  examining  the  numbers. 

Suppose  individual  ORUs  last,  on  average,  for  30  years.  That  means  some  will 
operate  longer  and,  more  importantly,  some  will  operate  less.  If  we  assume  a 
standard  failure  rate  probability  distribution  (Poisson),  there  is  a  6  percent  chance 
that  any  given  item  will  fail  in  the  first  2  years.  When  you  then  consider  that  an 
ORU  is  installed  in  five  separate  locations  on  the  station,  the  chance  of  a  failure  in 
2  years  increases  to  30  percent.  Add  to  that  failures  caused  by  accidents  or  the  harsh 
space  environment  and  the  chance  of  failure  may  increase  to  60  percent.  Next, 
consider  that  if  the  station  does  have  a  failure,  it  could  wait  2  to  5  years  before  the 
failed  item  can  be  returned  to  Earth,  repaired  or  replaced,  and  then  delivered  back  to 
the  station.  (Astronauts  will  have  limited  repair  capability.)  Even  with  redundant 
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systems,  that  is  a  long  time  to  wait  with  only  a  backup  between  you  and  an 
emergency  evacuation.  Finally,  if  the  chance  that  one  ORU  fails  is  60  percent,  then 
the  chance  of  a  failure  among  SSF’s  hundreds  of  ORUs  is  certain.  In  fact,  the 
question,  “Do  you  need  a  spare?”  quickly  changes  to  “How  many  spares  do  you  need?” 

Estimating  how  many  spares  the  station  requires  becomes  even  more  com¬ 
plicated  when  you  consider  many  spares  are  extremely  expensive  (in  the  $100,000  to 
$1  million  dollar  range)  and  that  spares  budgets  are  very  limited.  You  also  must 
decide  what  spares  can  be  brought  and  stored  in  the  station  and  what  spares  must 
stay  on  the  ground  because  shuttle  weight  and  station  storage  volume  is  also  severely 
constrained.  All  those  considerations  went  into  developing  the  M-SPARE  meth¬ 
odology. 

WHY  THIS  APPROACH? 

Another  question  is,  “What  does  this  method  do  that  other  approaches  fail  to 
do?”  The  answer  is  illustrated  in  Table  1-1.  That  table  compares  two  ways  of 
selecting  spares  for  a  hypothetical  station  that  contains  only  two  critical  ORUs.  The 
traditional  approach  treats  all  ORUs  the  same.  It  selects  spares  so  that  each  ORU 
has  a  95  percent  chance  of  having  at  least  as  many  spares  as  demands  (see  top  of 
Table  1-1).  Space  station  availability  is  the  probability  that  no  ORU  is  inoperative 
for  lack  of  a  spare,  which  is  the  product  of  the  two  probabilities  (90  percent).  That 
means  both  ORUs  are  operating  90  percent  of  the  time.  The  station  resource 
expenditure  is  $13:  $3  for  three  spares  of  ORU  A  at  $1  each,  and  $10  for  two  spares  of 
ORU  B  at  $5  each. 

However,  there  is  a  better  way  to  determine  a  spares  mix.  The  approach  focuses 
on  how  well  the  station  as  a  system  of  ORUs  is  performing  as  opposed  to  how  well 
each  ORU  is  performing.  Thus,  the  system  approach  does  not  treat  all  ORUs  the 
same  but  considers  that  their  failure  rates  and  costs  are  different.  Table  1-1  (bottom 
section)  demonstrates  that  by  slightly  changing  the  spares  mix  for  ORUs  A  and  B  to 
4  and  1,  respectively,  you  can  improve  the  station  availability  (from  90  percent  to 
91  percent)  and  reduce  cost  (from  $13  to  $9).  This  example  is  a  simplification  of  how 
the  M-SPARE  model  forecasts  spares  requirements.  Basically,  M-SPARE  sets 
priorities  for  spares  and  selects  the  spares  that  will  improve  the  station  availability 
the  most  per  unit  cost. 
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TABLE  1-1 


COMPARISON  OF  TWO  SPARES'  SELECTION  APPROACHES 


Traditional  Targets:  0.95 

Parameter 

ORU  A 

Cost  =  $1 

ORUB 

Cost  =  $5 

Space  station 

Performance  probability 

0.95 

0.95 

90% 

Number  of  spares 

3 

2 

— 

Cost  ($) 

3 

10 

13 

Optimal:  A  Better  Way 

Performance  probability 

0.98 

0.93 

91% 

Number  of  spares 

4 

1 

— 

Cost  ($) 

4 

5 

9 

To  prove  our  point,  we  evaluated  a  data  base  with  50  ORUs  using  the  first 
approach  and  selected  spares  so  that  each  ORU’s  performance  probability  would  be 
0.95  or  more.  This  procedure  resulted  in  an  expenditure  of  $106,840  and  station 
availability  of  approximately  25  percent.  For  the  same  $106,840,  M-SPARE  selected 
an  optimal  spares  list  that  produced  a  station  availability  of  73  percent,  almost  three 
times  greater  than  the  traditional  approach.  In  Chapter  7,  we  discuss  how  that 
analysis  can  be  duplicated. 

A  DETERMINISTIC  EXAMPLE 

To  help  define  and  explain  the  M-SPARE  methodology,  let’s  discuss  the  spares 
and  funding  estimates  for  a  simple  example  with  a  deterministic,  constant 
ORU  failure  rate.  Consider  one  ORU  with  a  180-day  logistics  cycle,  one  resupply 
flight  at  the  beginning  of  the  year  and  one  in  the  middle,  four  failiu-es  every  logistics 
cycle,  a  launch  date  of  October  1995  (the  beginning  of  FY96),  and  a  constant  failure 
rate. 


If  this  ORU  is  not  reparable,  then  our  spares  requirement  model  is  simple.  For 
FY96,  the  ORU  needs  4  spares  pre-positioned  on  orbit  on  Day  1  of  the  year  to  replace 
the  4  failures  over  the  course  of  the  first  logistics  cycle  and  then  4  more  ready  for  the 
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mid-year  launch  to  cover  the  second  logistics  cycle.  That  sums  to  a  spares 
requirement  of  8  for  the  entire  year.  The  cumulative  spares  requirements  increases 
to  12  in  the  beginning  of  FY97  and  then  16  in  the  middle  of  FY97.  Thus,  for  the 
nonreparable  example  item,  the  ‘'gross’*  spares  requirement  at  launch  equals  the 
cumulative  failures  (previous  failures  plus  the  expected  failures  in  the  next  cycle) 
shown  in  Row  2  of  Table  l-2a. 


TABLE  1-2a 

SPARES  REQUIREMENTS 
(DETERMINISTIC  FAILURES) 


However,  if  we  assume  that  the  broken  ORU  is  reparable  75  percent  of  the  time, 
the  generated  repairs  eventually  produce  serviceable  spares  to  replace  some  of  the 
failed  ORUs  and  slow  the  growth  of  the  gross  requirement.  In  our  example,  ORUs  do 
not  start  entering  the  repair  process  until  the  second  shuttle  flight  returns  with 
broken  ORUs  from  the  first  logistics  cycle.  We  assume  the  original  equipment 
manufacturer  (OEM)  requires  145  days  to  repair  them  so  they  are  available  by  the 
end  of  the  year.  Thus,  the  OEM  repairs  three  ORUs  (75  percent  repair  rate  times  four 
broken  ORUs)  in  time  for  the  third  shuttle  laimch.  From  then  on,  the  OEM  generates 
an  additional  three  repairs  each  logistics  cycle  (Row  3  of  Table  l-2b). 

We  can  now  calculate  spares  requirements  for  this  reparable  ORU  by 
subtracting  cumulative  repairs  from  cumulative  failures  (i.e.,  Row  2  -  Row  3  =  Row 
4  in  Table  l-2b).  To  calculate  the  maximum  gross  spares  requirements  in  the  year,  we 
use  the  requirements  for  the  second  logistics  cycle  (see  Row  5  of  Table  l-2b).  The  net 
spares  requirements  for  any  year  is  the  increase  in  requirements  from  the  previous 
year  (see  Row  6  of  Table  l-2b).  After  the  transition  year,  FY96,  the  net  spares  equals 
the  condemnations  per  year. 


TABLE  1-2b 


SPARES  REQUIREMENTS 
(DETERMINISTIC  FAILURES) 


Logistics 

cyd* 

Row 

FY96 

FY97 

FY98 

FY99 

a 

2 

3 

B 

5 

B 

B 

B 

Failures 

1 

■ 

■ 

4 

B 

4 

■ 

4 

4 

Cumulative  failures 

2 

D 

8 

12 

16 

20 

B 

28 

32 

Cumulative  repairs 

3 

KB 

0 

3 

6 

9 

mm 

15 

18 

Requirements 

4 

8 

9 

10 

11 

13 

14 

Gross  requirements/year 

5 

1 

8 

10 

12 

14 

Net  requirements/year 

6 

■ 

8 

2 

2 

We  next  spread  the  spares  price  (net  spares  times  unit  price)  across  the 
prociirement  lead  time  (PLT),  assumed  to  be  the  2  previous  years.  We  also  assume  we 
incur  60  percent  of  our  costs  in  the  first  year  and  40  percent  of  our  costs  in  the  second 
year  of  the  PLT.  (The  user  can  specify  those  percentages  as  input.)  Thus,  if  we  need 
eight  spares  in  FY96  with  a  unit  price  of  $125,000,  we  spend  $600,000  (eight  times 
$125,000  times  60  percent)  in  FY94  and  $400,000  in  FY95  (see  bottom  of  Table  l-2c). 
We  repeat  that  cost  spread  for  the  other  net  spares  requirements  in  the  next  3  years. 
We  develop  ORU  funding  requirements  {annual  budget  estimates)  by  summing  up  the 
dollars  for  each  fiscal  year.  If  we  follow  this  process  for  all  ORUs  and  for  all 
criticalities,  we  have  our  spares  and  funding  requirements  by  year. 

With  this  simple  example  as  background,  we  can  now  discuss  the  basic 
assumptions  of  the  model.  Later,  we  will  expand  upon  our  example  and  discuss  the 
more  complicated  probabilistic  processes  and  changing  failure  rate  implemented  in 
M-SPARE.  In  such  cases,  M-SPARE  adds  **safety”  margins  of  spares  to  the 
requirements  so  that  the  station  can  meet  unexpected  increases  in  demand. 

BASIC  MODEL  ASSUMPTIONS 

To  estimate  funding  requirements,  we  must  make  some  basic  assumptions. 
Those  assumptions  are  intended  to  accurately  reflect  possible  future  conditions  while 
keeping  the  M-SPARE  model  simple  and  understandable.  Figure  1-3  summarizes 
those  assumptions  for  a  single  model  year  —  FY98. 
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TABLE  1-2c 


SPARES  REQUIREMENTS 
(DETERMINISTK  FAILURES) 


Logistics 

cycio 

Row 

FY96 

FY97 

FY96 

FY99 

D 

2 

— 

3 

B 

5 

B' 

B 

B 

Failures 

Cumulative  failures 

Cumulative  repairs 

1 

2 

3 

1 

m 

4 

12 

3 

4 

16 

6 

4 

20 

9 

I 

Requirements 

Gross  requirements/year 

4 

5 

6 

1 

9 

I 

11 

1 

13 

1 

Outlays 

(SOOO) 

FY94 

FY95 

FY96 

1 

FY97 

1 

FY90 

1 

■1 

ForSSFFY96 

For  SSF  FY97 

ForSSFFYSa 

ForSSFFY99 

600 

■S 

1 

1 

mm 

1 

1 

!■ 

1 

1 

1 

Annual  budget  estimate 

600 

550 

250 

250 

100 

Outlays 


Model  spares  requirements 


FIG.  1-3.  OUTLAYS  MEET  FUTURE  SPARES  REQUIREMENTS  FOR  FY98 
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Since  the  SSF  budget  process  uses  annual  estimates,  we  need  to  develop  spares 
requirements  on  an  annual  basis.  In  addition,  we  need  sufficient  spares  to  satisfy  the 
year’s  most  demanding  requirement.  For  the  growing  SSF,  the  greatest  number  of 
failures  should  occur  at  the  end  of  the  year  when  SSF  is  at  its  largest  configuration. 
Since  M-SPARE  generates  spares  requirements  for  a  specific  logistics  cycle,  we  run 
M-SPARE  for  the  last  logistics  cycle  in  the  fiscal  year.  In  that  way,  M-SPARE 
requirements  are  based  upon  the  point  when  the  station  growth  is  the  largest.  [In 
exceptional  cases,  ORU  quantity  may  decline  over  time  (e.g.,  phasing  out  an  ORU)  so 
that  the  timeframe  also  ensures  that  we  do  not  buy  a  spare  we  later  will  not  need.] 
We  assume  that  all  ORU  logistic  cycles  end  at  the  end  of  the  fiscal  year  and  start  a 
logistics  cycle  earlier.  For  instance,  if  an  ORU  has  a  180-day  logistics  cycle,  we 
assume  the  last  logistics  cycle  starts  on  the  seventh  month  of  the  fiscal  year;  if  an 
ORU  has  a  135-day  logistics  cycle,  we  assume  the  last  logistics  cycle  starts  on  the 
eighth  month  of  the  fiscal  year.  Eventually,  NASA  might  want  to  input  actual 
logistics  resupply  flight  schedules  into  M-SPARE,  but  for  now  and  for  a  budget 
model,  we  believe  this  level  of  detail  is  adequate. 

Next,  we  assume  that  spares  deliveries  arrive  at  the  beginning  of  each  fiscal 
year.  That  assumption  forces  all  orders  to  be  placed  a  PLT  earlier  (in  Figure  1  -3,  that 
is  at  the  beginning  of  FY96).  We  also  assume  that  outlays  for  the  procurement  occur 
over  the  entire  lead  time  (e.g.,  a  2-year  PLT;  FY96  and  FY97).  The  percent  of  unit 
price  that  occurs  each  PLT  year  (e.g.,  60  percent  in  FY96  and  40  percent  in  FY97)  is 
determined  by  a  user-specified  spread  vector. 

For  two  reasons  we  assume  the  station  receives  all  orders  at  the  beginning  of  a 
fiscal  year.  One  reason  is  to  simplify  the  budget  outlay  calculations.  The  outlays  now 
fall  in  the  same  number  of  fiscal  years  as  the  PLT,  and  we  can  easily  apply  and  track 
the  spread  vector  percentages.  The  more  important  reason  is  to  ensure  dollars  are 
budgeted  and  spares  delivered  in  time  to  meet  all  requirements.  In  practice,  the 
station  does  not  need  all  spares  on  Day  1  of  the  year.  However,  the  station  does  need 
many  spares  early  in  the  year  to  be  loaded  for  the  first  shuttle  launch,  which  is 
assumed  to  occur  at  the  beginning  of  the  year.  Also,  all  spares  must  be  delivered  by 
the  last  shuttle  launch  of  the  year,  which  occurs  near  the  middle  of  the  year.  The 
same  Figure  1-3  process  repeats  itself  for  each  requirement  year  thereafter. 
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Finally,  we  assume  that  the  PLT  includes  the  time  from  when  the  broken 
ORU  is  brought  down  to  the  ground  to  the  time  a  new  one  is  procured  and  is  ready  to 
be  loaded  on  the  shuttle.  That  means  the  PLT  includes  production  time,  adminis¬ 
trative  time,  shuttle  launch  processing  time,  order  and  shipping  time,  and  all  other 
delays  that  may  occur.  Users  can  specify  the  PLT  for  each  ORU  (from  1  to  5  years) 
and  the  corresponding  spread  vector  for  each  year. 

Eventually,  NASA  might  want  to  modify  those  assumptions.  For  instance, 
when  NASA  actually  orders  spares,  they  will  probably  place  orders  throughout  the 
year  and  run  M-SPVRE  at  more  frequent  intervals,  perhaps  even  before  every 
procurement.  That  may  cause  the  spares  requirements  to  fall  in  to  more  than  one 
fiscal  year.  We  believe  that  at  this  early  stage  of  station  development  and  for  the 
aggregate  projections  of  a  budget  model,  more  complex  assumptions  are  unnecessary. 

In  summary,  M-SPARE  includes  a  number  of  key  assumptions: 

•  Gross  spares  requirements  are  calculated  on  an  annual  basis  and  represent 
the  maximum  requirements  for  the  fiscal  year. 

•  Net  spares  requirements  (gross  requirements  minus  assets)  are  delivered  at 
the  beginning  of  the  fiscal  year  and  are  ordered  a  PLT  earlier. 

•  Budgets  are  outlays  that  accrue  over  a  specific  fiscal  year  of  the  PLT. 

•  Those  outlays  are  distributed  to  each  PLT  year  based  upon  a  spread  vector 
that  defines  what  percentage  of  the  ORU  unit  price  is  accrued  in  each  of  the 
PLT  years. 

•  The  PLT  includes  the  time  from  when  the  broken  ORU  is  returned  to  Earth 
until  the  time  a  new  ORU  is  procured  and  loaded  on  the  shuttle. 

•  All  costs  are  assumed  to  be  in  constant  dollars  with  the  baseline  year 
equaling  the  year  of  the  ORU  unit  price  unless  otherwise  specified. 

•  All  time  units  for  spares  and  funding  requirements  are  fiscal  years  unless 
otherwise  specified. 

USERS  AND  USES 

The  M-SPARE  model  is  being  used  at  all  NASA  SSF  project  offices  and  their 
prime  contractors  and  at  the  Canadian  Space  Agency  to  estimate  SSF  spares 
requirements  (the  other  international  partners  have  also  received  copies  of  the 
model).  Specifically,  M-SPARE  is  used  at  project  offices  in  the  POP  cycle  to  produce 
two  basic  products.  The  first  POP  product  presents  the  spares  and  funding 


1-13 


requirements  or  what  the  station  ideally  would  like  to  have.  The  user  inputs  yearly 
availability  targets,  and  M-SPARE  generates  spares  requirements  for  the  first  years 
of  the  station’s  life  (e.g.,  FY96  to  FY04)  and  the  corresponding  funding  requirements 
for  the  next  9  fiscal  years  (FY94  to  FY02>  that  meet  those  specified  targets.  That 
method  is  described  in  the  Basic  Model  Assumptions  section  of  this  chapter  and  is 
what  we  term  the  spares  requirements  product. 

For  the  second  POP  product,  the  user  inputs  the  expected  annual  budgets  for 
the  next  9  fiscal  years,  and  M-SPARE  determines  how  many  spares  NASA  can  buy 
with  these  funds.  We  will  refer  to  those  input  budgets  as  annual  POP  marks  and  the 
output  as  the  spares  constrained  budget  product.  It  is  more  difficult  to  produce  the 
constrained  product.  As  we  will  discuss  in  Chapter  9,  M-SPARE  does  produce  spares 
estimates  based  upon  the  POP  marks. 
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CHAPTER  2 


INSTALLATION  AND  DEMONSTRATION 


In  this  chapter,  we  explain  how  to  install  the  model,  how  to  operate  the  user 
interface,  and  how  to  take  the  model  on  a  quick  test  drive.  This  version  of  M-SPARE 
is  self-contained  so  that  the  user  can  edit  input  files,  set  options,  operate  the  wear 
preprocessor  (see  Chapter  10),  and  run  the  model  all  within  the  M-SPARE  interface. 

INSTALLATION 

To  install  the  M-SPARE  model,  log  on  to  your  computer.  Insert  our  floppy  disk 
into  your  drive  (our  example  assumes  this  will  be  the  A  drive  but  any  high-density 
5.5  inch  floppy  drive  works).  The  commands  listed  below  make  a  new  directory  called 
SPARE  on  your  hard  disk  drive  (our  example  assumes  this  will  be  the  C  drive,  but 
again  any  hard  drive  works)  and  copy  the  required  files  from  our  floppy  disk  to  the 
new  SPARE  directory.  [Note:  All  characters  enclosed  in  double  quotations  are  the 
commands  you  enter  or  select  from  your  PC  keyboard  usually  followed  by  pressing 
the  “Enter”  key.  You  do  not  need  to  enter  the  quotation  marks  themselves.] 

•  Enter  “A:”  —  the  drive  where  our  floppy  disk  is. 

•  Enter  “INSTALL  C”  to  install  the  model  on  your  C  drive. 

•  Press  any  key  to  complete  installation. 

When  the  installation  is  finished,  you  will  see  a  Disk  Operating  System  (DOS) 
prompt  on  your  screen.  At  that  point,  M-SPARE  and  its  accompanying  interface  are 
installed  and  you  are  ready  to  run  the  model. 

INTERFACE  OPERATION 

Now  that  the  model  is  installed,  we  will  discuss  what  is  necessary  to  run  the 
model. 

.•  If  your  system  is  not  already  in  the  SPARE  directory,  type  “CD\SPARE”  to 
move  there. 

•  Type  “START”  to  enter  the  M-SPARE  interface. 
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Your  computer  screen  now  resembles  Exhibit  2-1,  and  you  can  choose  one  of  five 
choices  displayed  in  the  menu  bar  at  the  top.  [Note:  All  exhibits  (figures  in  a  box)  in 
this  report  represent  information  that  may  appear  on  your  computer  monitor.  ]  The 
user  can  select  a  menu  choice  in  three  ways.  (1)  use  the  left  or  right  arrow  keys  to 
move  the  highlight  bar  to  the  menu  option  and  then  press  the  “Enter”  key,  (2)  press 
the  highlighted  red  letter  in  each  menu  choice,  or  (3)  click  on  the  option  with  your 
mouse.  The  bottom  line  of  the  interface  reminds  you  to  press  the  function  key  “FI”  to 
access  the  menu  or  press  the  “ALT-X”  key  combination  to  terminate  M-SPARE  after 
executing  the  model.  Each  of  the  following  menu  choices  corresponds  to  one  of  the 
steps  required  to  run  M-SPARE  and  analyze  its  results. 


View 


If  you  select  the  “View”  choice,  a  menu  box  appears  (see  Exhibit  2-2)  and  the 
user  can  select  various  options  to  view  M-SPARE  ORU  inputs  (see  Chapter  5)  and 
outputs  (see  Chapter  8).  The  first  step  in  running  the  model  is  to  examine  the  ORU 
data  base,  MSPAREIN.RPT,  to  make  sure  the  appropriate  data  exists.  From  this 
point,  you  can  also  examine  the  summary  and  detail  output  report  files 
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(BUDGET.RPT  and  OUT.RPT,  respectively)  once  you  run  the  model.  The  computer 
automatically  stores  the  output  reports  from  your  previous  run  (OLDOUT.RPT  and 
OLDBUD.RPT).  In  general,  the  “View”  choice  allows  the  user  to  access  a  powerful 
commercial  text  editor  called  Vedit.  Vedit  can  view  and  edit  large  files,  examine 
several  files  at  once,  and  perform  a  host  of  other  functions  described  in  the 
accompanying  Vedit  User’s  Manual.  Once  in  the  editor,  press  the  “FI”  key  to  display 
its  menu  choices.  To  access  only  the  editor,  select  the  “Editor”  option.  If  you  then 
change  your  mind  while  in  the  “View”  menu  box,  and  want  to  step  back  to  the 
previous  menu,  just  press  the  “Esc”  key.  [Note:  If  your  package  does  not  contain  a 
text  editor  or  you  want  to  use  your  own,  copy  your  editor  into  the  SPARE 
subdirectory  and  name  it  Vedit  (i.e.,  Vedit.exe  or  Vedit.com).  MS-DOS  5.0  now  has 
an  editor  that  allows  you  to  access  large  files  so  you  may  want  to  use  that  editor.] 


View  Options  Hear 


Budget . RPT 

F3 

Out.RPT 

F4 

OldBud.RPT 

F5 

OldOut.RPT 

F6 

MSPAREIN.RPT 

F7 

Editor 

F8 

Run 


FI  Menu 


ALT-X  Exit 


EXHIBIT  2-2.  VIEW  MENU 


Options 

The  second  step  in  running  the  model  is  to  set  the  basic  model  options.  The 
“Options”  menu  choice  opens  the  options  file  that  provide  a  set  of  key  parameters  that 
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usually  do  not  vary  from  one  model  run  to  the  next.  Chapter  6  describes  how  to 
change  options  and  what  each  options  does. 

Wear 

The  third  step  in  running  the  model  is  to  set  up  and  run  the  wear  preprocessor. 
This  step  is  required  only  if  the  MSPAREIN.RPT  file  under  the  “View”  menu 
contains  ORUs  that  may  wear  out  during  the  model  time  horizon.  If  that  is  the  case, 
the  wear  preprocessor  only  needs  to  be  run  once  or  whenever  a  demand  factor  changes 
in  the  MSPAREIN.RPT  file  or  the  launch  schedule  changes  in  the  OPTIONS.RPT 
file.  The  preprocessor  simulates  an  ORU’s  wear  rate  and  random  failure  rate  and 
then  estimates  an  aggregate  failure  rate  (i.e.,  mean  demand).  That  rate  is 
automatically  used  in  the  spares  calculation.  For  more  information  on  the  operations 
of  the  preprocessor,  see  Chapter  10. 

Run 


Once  you  view  the  input,  check  the  options,  and  execute  the  wear  preprocessor 
(if  necessary),  then  select  the  menu  choice  “Run”  to  execute  the  model  and  calculate 
spares  and  budget  estimates.  Chapter  7  describes  the  user  queries  required  for 
M-SPARE  operation.  After  each  M-SPARE  run,  the  user  is  returned  to  the  initial 
interface  screen  to  examine  the  results  using  the  “View”  choice  or  rerun  the  model 
using  the  “Run”  choice. 

Exit 


When  you  are  finished  with  M-SPARE  and  the  interface,  select  the  “Exit” 
choice  to  exit  the  interface  and  return  to  DOS. 

QUICK  TEST  DRIVE 

To  present  an  overview  of  the  M-SPARE  operations  and  capabilities,  we  will 
take  you  on  a  test  drive.  We  have  already  set  the  options  and  a  sample  data  base  for 
you.  You  will  need  to  take  about  10  minutes  to  enter  the  inputs  we  specify.  Our  goal 
is  to  determine  spares  requirements  for  the  first  8  years.  The  sample  station  is  a 
single  system,  the  electric  power  system  (EPS)  with  only  Criticality  Code  1  ORUs.  In 
Chapter  7,  we  discuss  in  detail  the  meaning  of  the  queries  and  model  plots.  For  now, 
we  merely  present  an  overview  of  the  model  operation. 
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To  begin,  make  sure  you  are  in  the  model  interface.  If  you  have  questions,  see 
the  interface  operation  section  near  the  beginning  of  this  chapter.  Enter  “R”  to  run 
the  M-SPARE  model.  The  model  flashes  the  M-SPARE  title  page  and  then  asks  you 
to  select  a  criticality  code.  Enter  “1”  for  Criticality  Code  1.  Next,  the  modei  will  ask 
you  to  enter  information  year  by  year. 

First  Model  Year:  FY98 

Enter  “R”  to  run  the  first  model  year  and  “G”  to  select  the  Ground-Stock-Only 
option  from  the  Run  menu.  This  reflects  the  fact  that  there  will  be  no  on-orbit  spares 
storage.  Once  in  the  Ground-Stock-Only  Mode  Dialog,  press  the  “Tab”  key,  then 
press  the  down  arrow  to  select  a  ground  availability  target.  Press  the  ‘Tab”  key 
again  to  move  to  the  next  query  and  enter  a  “S5”.  Then,  press  the  “Enter”  key  to  run 
M-SPARE  for  FY98.  In  less  than  a  minute,  the  resource-versus-ground  availability 
curve  (see  Exhibit  2-3)  appears  on  the  screen.  Ground  availability  estimates  the 
performance  only  of  the  ground  inventory,  our  current  assumption.  That  is  the 
probability  the  ground  inventory  supplies  all  spares  needed  to  replace  the  on-orbit 
failures  from  the  previous  cycle.  As  we  discuss  in  Chapter  4,  it  is  similar  to 
measuring  station  availability  used  when  both  on-orbit  and  ground  inventories  are 
available. 

The  curve  presents  all  possible  ground  availabilities  under  varying  invest¬ 
ments.  The  solid  area  corresponds  to  the  95  percent  availability  target  you  entered 
and  defines  the  initial  spares  list.  It  shows  that  to  reach  95  percent  availability,  we 
require  a  spares  investment  of  about  $95  million.  The  spares  list  associated  with  that 
point  is  stored  in  the  output  file  that  we  discuss  in  Chapter  8.  Press  the  “Enter”  key 
to  remove  the  plot  and  continue. 

Modei  Year  2:  FY99 

To  run  the  next  model  year,  FY99,  for  the  same  availability  target,  press 
“Enter”  to  run  the  model  and  “G”  to  select  the  Ground-Stock-Only  option  from  the 
run  menu.  Press  ‘Tab”,  then  press  “Enter”  (no  additional  selection  is  required 
because  the  model  defaults  are  the  inputs  from  the  previous  year).  In  less  than  a 
minute,  the  resource-versus-ground-availability  curve  (see  Exhibit  2-4)  appears  on 
the  screen.  The  new  curve  is  different  from  the  previous  curve.  The  straight  line  part 
of  the  curve,  from  0  investment  to  $95  million,  displays  the  systems  performance  with 
only  last  year’s  spares  investment  (the  starting  asset  position  for  FY99).  The  curve 
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EXHIBIT  2-3.  RESOURCE-VERSUS-GROUND  AVAILABILITY  CURVE:  PTBB 


RESOURCE  vs  GROUND  AVAILABIIJTY;1999 

Re9o\irce=(1.0)$K  +  (0.0)LB  +  (0.0)IN-3 


EXHIBIT  2-4.  RESOURCE-VERSUS-GROUND  AVAILABILITY  CURVE:  FY99 


from  $95  million  to  $140  million  displays  the  net  requirements  needed  to  reach  a  95 
percent  availability.  In  other  words,  the  curve  illustrates  that  with  the  growth  of  the 
EPS  in  the  current  fiscal  year,  the  previous  spares  inventory  only  brings  the 
predicted  system  availability  up  to  60  percent.  The  system  requires  a  total 
investment  of  about  $140  million  to  reach  a  95  percent  availability  in  FY99. 

Model  Year  3:  FYOO 

In  the  next  model  year,  we  suppose  that  on-orbit  storage  is  available.  Price  and 
weight  of  each  ORU  is  also  considered.  You  press  “R”  to  run  the  model  year  and 
“Enter”  to  select  the  Multiple-Pass:  Orbit  &  Ground  option  (i.e.,  assumes  levels  of 
orbit  and  ground  storage).  Once  in  the  Multiple-Pass-Mode  Dialog,  keep  pressing 
“Tab”  until  you  highlight  the  last  query,  enter  an  Availability  Target  from  0  to  100 
percent,  and  then  type  “95”  and  press  “Enter”  to  start  the  model  run  for  model  year  3. 
The  model  runs  a  number  of  tradeoff  passes  between  price  and  weight  (the  tradeoff 
you  selected).  Each  pass  reduces  the  total  weight  of  the  on-orbit  spares  at  a  related 
price  penalty  (see  Chapter  3  for  more  information). 

After  a  couple  of  minutes,  a  resource-versus  availability  curve  such  as 
Exhibit  2-4  appears  on  the  screen.  It  shows  that  to  reach  95  percent  availability,  we 
need  resources  of  about  $195  million  and  14,000  pounds  (see  the  exhibit’s  second  and 
third  X-axes,  respectively). 

Press  “Enter”  to  display  possible  price-versus-weight  tradeoff  solutions  for  all 
passes  at  a  95  percent  availability  (see  Exhibit  2-5).  The  plot’s  top  left  point  is  the 
minimum  price  solution.  As  you  move  to  the  right,  total  weight  is  reduced  but  at  a 
price  penalty.  The  solution  M-SPARE  automatically  selects  is  near  the  elbow  of  the 
curve.  We  discuss  how  you  can  select  other  solution  points  in  Chapter  7.  Thus, 
M-SPARE  calculates  spares  requirements  based  upon  price  and  weight  and  also 
presents  a  range  of  possible  solutions.  Press  “Enter”  to  remove  the  plot  and  continue. 

Model  Years  4  to  7 :  FY01  to  FY05 

The  next  5  model  years  also  assume  on-orbit  storage  and  a  95  percent 
availability.  For  each  year,  enter  the  following  sequence  of  inputs.  Press  “R”  to  run 
the  model.  Press  “Enter”  to  select  the  Multiple-Pass:  Orbit  &  Ground  option.  Once 
in  the  Multiple-Pass-Mode  Dialog,  press  “Tab”  and  then  “Enter”.  The  model  does  not 
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EXHIBIT  2-5.  ITERATIVE  PRICE-VERSUS-WEIGHT  TRADEOFF  SOLUTIONS;  FYOO 


require  you  to  enter  a  95  percent  availability  because  that  input  did  not  change  from 
the  previous  year. 

As  in  the  analysis  of  FYOO,  the  model  displays  the  resource-versus-availability 
curve  and  the  iter ative-price-versus- weight  solutions  curve.  When  you  are  finished 
examining  a  curve,  press  “Enter”  to  continue. 

Notice  that  in  FY02,  the  resource-versus-availability  curve  takes  an  unusual 
shape.  This  is  because  the  ORU  batteries  in  the  data  base  are  estimated  to  last 
approximately  5  years  before  they  wear  out.  FY02  is  the  fifth  year  of  their  life  and 
many  will  need  to  be  replaced.  The  previous  year’s  spares  bring  the  station 
availability  up  to  only  15  percent.  However,  once  the  system  adds  batteries,  the 
availability  shoots  up. 

After  you  enter  variables  for  FY05,  your  work  is  over.  The  model  then 
calculates  the  estimates  for  the  budgets  along  with  other  information  and  stores 
them  in  the  appropriate  files  (see  Chapter  8).  The  model  also  produces  a  summary 
plot  for  spares  weight  (sometimes  referred  to  as  upweight  or  upmass)  estimates  (see 
Exhibit  2-6).  The  model  produces  a  host  of  other  summary  tables  stored  in  output 
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EXHIBIT  2-6.  ANNUAL  SPARES  UPWEIGHT  ESTIMATES 


files,  but  displays  weight  information  because  it  presents  a  glimpse  of  M-SPARE’s 
additional  capabilities. 

Exhibit  2-6  summarizes  two  types  of  spares  weight  for  all  model  years.  The 
solid  line  displays  the  spares  weight  for  all  shuttle  launches  in  a  particular  year. 
Those  laimches  allow  astronauts  to  pre-position  spares  in  space  to  replace  anticipated 
failures.  M-SPARE  estimates  that  launches  to  pre-position  spares  occur  mostly  in 
2  specific  years:  in  FYOO  (the  first  time  on-orbit  storage  volume  becomes  available) 
and  in  FY02  (in  order  to  replace  worn  out  batteries).  Otherwise,  the  on-orbit 
inventory  levels  remain  relatively  constant.  The  other  weight  resource  type  in 
Exhibit  2-6  (dotted  line)  is  the  resupply  weight  of  the  spares.  The  resupply  weight 
estimates  the  movement  of  spares  from  the  ground  to  the  station.  M-SPARE  assumes 
that  shuttles  resupply  SSF  with  spares  that  replenish  on-orbit  inventory  or  replace 
failed  ORUs  if  no  inventory  is  available.  To  estimate  the  resupply  weight,  M-SPARE 
multiplies  an  ORlTs  average  number  of  failures  in  a  year  times  its  unit  weight  and 
then  sums  across  all  ORUs  for  all  criticalities.  We  display  resource  types  to  present 
the  complete  picture  of  spares  weight  requirements  (the  combination  of  on-orbit  and 


2-9 


resupply  weight).  As  with  budget  constraints,  SSF  must  eventually  meet  weight  and 
volume  constraints  so  M-SPARE  must  also  estimate  those  requirements. 

When  you  are  finished  examining  the  upweight  estimates  press  “Enter”  and 
you  return  to  the  user  intt  rface  discussed  at  the  beginning  of  this  chapter.  You  can 
now  “View”  the  outputs  or  wait  until  we  discuss  outputs  in  Chapter  8. 

PC  REQUIREMENTS 

The  model  operates  on  IBM-compatible  PCs  with  about  two  megabyte  of  hard 
disk  storage  and  about  250  kilobytes  of  memory  to  run  50  ORUs.  A  rough  rule  of 
thumb  is  that  every  ORU  above  the  50  will  require  an  additional  half  of  a  kilobyte  of 
memory.  A  PC  with  a  math  coprocessor  runs  the  model  about  10  times  faster  than 
one  without  a  coprocessor. 

The  model  input  and  output  data  are  text  or  ASCII  (American  Standard  Code 
for  Information  Interchange)  files  so  that  you  can  browse  them  with  your  editor  or 
word  processor.  You  can  avoid  using  the  interface  if  you  prefer  to  view  the  text  files 
this  way.  Just  type  “MSPARE”  to  run  the  model  from  the  C:\SPARE  DOS  prompt. 

The  key  M-SPARE  input  and  output  files  in  your  C:\SPARE  subdirectory  are 
the  following: 

•  MSPARE.EXE  —  the  M-SPARE  model  in  an  executable  form. 

•  MSPAREIN.RPT  —  a  text  file  that  now  contains  sample  input  data  from 
three  station  subsystems  and  about  50  ORUs  and  eventually  will  contain 
your  ORU  data  base. 

•  OPTIONS. RPT  —  the  options  text  file  that  allows  you  to  change  detailed 
model  options  without  recompiling  a  new  executable  file. 

•  BUDGET.RPT  —  a  text  file  that  contains  the  summary  estimates  of  gross 
and  net  spares  and  funding  requirements. 

•  OUT. RPT  —  the  text  output  file  in  which  the  detailed  spares  results  that 
generate  the  summary  results  of  the  BUDGET.RPT  file  are  stored. 

We  describe  the  pertinent  user  files  in  more  detail  in  the  subsequent  chapters  of 
this  guide. 
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CHAPTER  3 


SPARES  PRIORITIZATION  OVERVIEW 


The  heart  of  the  model  is  the  process  that  sets  priorities  for  spares.  That  process 
builds  a  prioritized  “shopping  list”  for  spares  based  upon  each  spare’s  benefit-to-cost 
ratio.  At  the  top  of  the  shopping  list  is  the  spare  that  has  the  greatest  marginal 
benefit  to  station  availability  per  resource  expenditure,  or  the  biggest  “bang  for 
buck.”  Selecting  in  the  order  indicated  on  the  list  yields  the  maximum  availability 
rate  for  the  resource  expended.  The  optimization  process  assures  that  no  other 
combination  of  spares  will  give  a  higher  availability  for  the  same  resource  expen¬ 
diture  or  the  same  availability  for  a  lower  resource  expenditure.  As  one  moves  down 
the  priority  list  and  adds  spares  to  those  alrt  ady  selected,  the  station  availability  and 
resource  expenditure  increases,  always  yielding  an  optimum  mix.  The  entire  selec¬ 
tion  process  creates  the  resource- versus  availability  curve  (see  Exhibit  2-3),  and  each 
spare  selected  creates  a  point  on  that  curve. 

Significantly,  the  model  can  work  on  any  “physical  system”  or  set  of  ORUs.  For 
this  chapter,  we  will  define  the  set  as  the  critical  ORUs  on  the  station.  However,  the 
same  discussion  can  apply  to  the  set  of  critical  ORUs  at  any  level:  distributed  system, 
subsystem,  or  sub-subsystem. 

Another  significant  point  is  that  the  M-SPARE  model  uses  the  benefit-to-cost 
ratio  and  assumes  that  all  ORUs  are  of  equal  importance  —  if  any  ORU  fails,  it  will 
create  the  same  detrimental  impact  on  the  station  as  any  other  ORU.  For  instance, 
the  model  does  not  consider  that  critical  life  support  ORUs  are  more  important  than 
noncritical  lighting  ORUs  in  the  spares  selection  process.  That  means  the  model  can 
only  handle  one  classification  of  ORUs  at  a  time.  Thus,  the  user  has  at  least  three 
sets  of  ORUs  (Criticality  Codes  1,  2,  and  3).  The  model  handles  each  set  separately. 
Another  reason  for  separating  ORU  types  is  that  Criticality  Code  1  spares  are  stored 
on  orbit  and  on  the  ground  while  other  spares  are  stored  only  on  the  ground.  We 
initially  assume  spares  can  be  stored  at  either  location  and  then  we  discuss  how  the 
model  handles  a  case  in  which  spares  are  stored  on  the  ground  only. 


In  the  remainder  of  this  chapter,  we  present  an  overview  of  model  methodology 
in  three  sections; 

•  Station  AvaUability.  We  define  availability  as  the  probability  that  no 
system  is  inoperative  for  lack  of  a  spare  ORU  over  the  logistics  cycle. 

•  Spares  Prioritization  Across  ORUs.  We  define  the  process  for  prioritizing 
the  ORU  spare  that  yields  the  greatest  bang  for  buck  (highest  station 
availability  per  resource  expended). 

•  Multiple  Resource  Optimization.  We  discuss  how  the  model  manages  several 
resources  separately  and  in  combination,  a  feature  that  allows  the  user  to 
balance  conflicting  resource  expenditures. 

STATION  AVAILABILITY 

A  major  advantage  of  the  M-SPARE  methodology  is  that  it  links  the  .’pares  mix 
directly  to  station  availability.  To  understand  the  spares  selection  process,  cne  must 
first  understand  how  M-SPARE  derives  station  availability. 

We  assume  the  station  starts  each  logistics  cycle  after  the  shuttle  has 
resupplied  it  with  a  complement  of  spares.  Those  spares  are  intended  to  satisfy 
demands  (replace  failures)  over  the  logistics  cycle  (i.e.,  until  the  next  shuttle  provides 
resupply).  For  the  station  to  be  available  over  the  entire  logistics  cycle,  each  ORU 
must  either  experience  no  failures  or  have  at  least  one  on-orbit  spare  replacement  for 
every  failure.  We  term  the  likelihood  of  that  condition  as  the  ORU  “probability  of  a 
spare  when  needed”  (PSN).  Thus,  assuming  independence  of  failures  across  ORUs: 

station  availability  =  n  PSNi{s,),  [Eq.3-11 


where 

Si  =  number  of  spares  for  OR  Ui 
i  =  ORU  index. 

The  ORU  PSN  used  in  M-SPARE  is  related  to  the  standard  ORU  probability  of 
sufficiency  (POS)  measure,  but  additional  factors  are  considered.  Both  consider  the 
length  of  time  a  broken  ORU  spends  in  the  maintenance  process,  the  length  of  the 
logistics  cycle,  and  the  number  of  on-orbit  ORU  failures  during  that  cycle.  However, 
in  M-SPARE,  the  ORU  PSN  includes  the  possibility  of  starting  the  logistic?  ^ycle 
with  fewer  than  the  desired  number  of  on-orbit  spares  because  the  ground  stock  is  not 


available  at  shuttle  launch.  Further,  M-SPARE  accounts  for  the  different  benefits  of 
spares  stored  on  orbit  and  on  the  ground  —  it  performs  an  optimal  multi-echelon 
tradeoff.  An  on-orbit  spare  has  a  greater  benefit  to  station  availability  because  it  is 
more  accessible;  a  ground  spare  has  lower  resource  expenditure  because  it  imposes  no 
penalties  for  weight  at  shuttle  launch  or  on-orbit-storage-volume.  We  present  a 
detailed  discussion  of  the  calculation  of  ORU  PSN  and  the  multi-echelon  tradeoff  in 
Chapter  4.  For  now,  we  assume  that  information  is  available. 

Thus,  station  availability  is  an  indication  of  how  well  the  entire  space  station 
performs  its  mission,  given  a  certain  spares  mix.  We  do  not  imply  that  the  model 
produces  an  all-inclusive  view  of  station  availability;  rather,  it  merely  considers 
hardware  (ORU)  failures.  However,  the  station  may  not  be  available  for  other 
reasons  such  as  lack  of  fuel  or  lack  of  crew  time  to  replace  a  failed  ORU  even  if  a  spare 
is  at  hand.  Nevertheless,  the  model  does  capture  the  most  important  factors  required 
to  estimate  spares.  [M-SPARE  may  be  linked  with  other  models  such  as  Simulation 
of  Manned  Space  Station  Logistics  Support  (SIMSYLS)  or  Reliability  and 
Maintainability  Assessment  Tool  (RMAT)  to  estimate  impacts  of  those  other  factors.] 

SPARES  PRIORITIZATION  ACROSS  ORUs 

Marginal  Benefit-to-Cost  Ratio 

The  first  step  required  to  develop  our  shopping  list  of  spares  is  to  determine  the 
bang-for-buck  measure  (i.e.,  the  marginal  benefit-to-station  availability  divided  by 
unit  resource  expenditure)  for  each  ORU  spare.  Let  us  now  discuss  the  steps 
necessary  to  develop  the  methodology.  Appendix  A  provides  mathematical  proof  that 
our  methodology  produces  an  optimum  solution. 

The  methodology  objective  is  to  maximize  the  availability  in  Equation  3-1 
subject  to  a  constraint  on  spares  investment.  Note  that  Equation  3-1  is  a  product  of 
the  item  decisions,  whereas  spares  investment  is  the  sum  of  costs  on  each  item. 

We  need  to  convert  the  optimization  problem  into  a  sum  of  terms,  so  that  the 
availability  contribution  and  spares  cost  are  additive  across  items.  This  can  be  done 


by  taking  the  logarithm  of  availability  in  Equation  3-1  since  a  function  and  its 
logarithm  achieve  their  maximum  at  the  same  point  (see  Equation  3-2). 


In  (station  availability)  =  [  PSN^  •«,)]. 

i 


[Eq.  3-2] 


Let  Si  designate  the  optimal  policy  for  each  ORUi  that  produces  the  largest 
availability  for  some  total  investment  in  spares  (e.g.,  S(  =  0  for  all  items  i  when  the 
investment  is  0).  Then,  the  next  item  to  buy  is  that  item  which  gives  the  maximum 
increase  in  the  logarithm  of  availability  per  unit  resource.  This  is  called  marginal 
analysis  and  is  generalized  with  the  following  equation: 


marginal  benefit^ 
unit  resource^ 


ln[  PSNi  (  sj-t- 1 )]  -  Zn  [  PSN,  ' s, ) 


unit  resource^ 


[Eq.  3-3] 


Example  of  the  Prioritization  Process 

To  explain  the  prioritization  process,  we  use  a  simple  example  for  a  few  ORUs 
and  assume  price  (dollars)  is  the  resource  type.  We  start  the  process  by  solving 
Equation  3-2  for  the  station  availability  with  no  resource  expenditures  (e.g.,  Si=0  for 
all  items).  In  the  example  given  in  Table  3-1,  that  value  is  equal  to  22.8  percent. 

TABLE  3-1 

EXAMPLE  OF  SPACE  STATION  AVAILABIUTY  COST  CURVE 


Curve 

ORU  spares 
prioritized 
(shopping  list) 

Bang  for  buck: 
marginal  benafH 

cost 

Unit  resource 
(dollars) 

Total 

resource 

(dollars) 

Space  station 
availability 
(percent) 

0 

22.8 

.... 

1 

39.6 

Filter 

0.554 

1 

2 

45.8 

Filter 

0.146 

1 

7 

79.8 

Valve 

0.111 

5 

10 

• 

• 

• 

82.4 

Sensor 

0.033 

3 

-4 


3 


Next,  the  model  checks  all  ORUs  and  chooses  the  one  with  the  largest  marginal 
benefit-to-cost  ratio  (i.e.,  the  filter  with  a  ratio  of  0.554).  It  then  increases  the  station 
availability  by  the  marginal  benefit  to  39.6  percent  and  increases  the  total  resource 
expenditure  by  the  $1  unit  cost  of  the  filter.  The  selection  of  the  filter  creates  the 
second  point  on  our  curve  (first  two  columns  of  Table  3-1).  Next,  the  model  calculates 
a  new  benefit-to-cost  ratio  for  the  filter  using  Equation  3-3.  Now  the  marginal 
benefit  is  the  difference  between  obtaining  the  second  and  the  first  spare  (i.e.,  0.146). 
At  that  point,  the  process  is  repeated.  The  model  selects  the  spare  with  the  next 
biggest  benefit-to-cost  ratio  (again,  the  filter);  increments  the  resource  expenditure 
and  station  availability  to  $2  and  45.8  percent,  respectively;  and  recalculates  a  new 
benefit-to-cost  ratio  for  the  third  filter.  The  model  continues  to  repeat  that  process 
until  the  space  station  availability  is  close  to  100  percent. 

A  final  feature  of  the  model  is  its  ability  to  generate  the  spares  mix  for  a  user- 
specified  resource  or  availability  target.  The  model  uses  the  resource  target  as  the 
maximum  resource  expenditure  and  the  availability  target  as  the  minimum  station 
performance.  To  generate  the  spares  mix,  the  model  checks  each  point  as  it  processes 
the  curve.  When  it  reaches  the  point  at  which  the  curve  value  first  becomes  greater 
than  the  target  value,  it  stops.  If  the  user  selected  an  availability  target,  the  model 
stores  the  spares  level  for  each  ORU.  If  a  resource  target  is  given,  the  model  goes  to 
the  next  to  last  spare  so  that  it  will  not  exceed  the  resource  target.  The  model  then 
stores  the  spares  list. 

In  our  example,  if  we  want  a  spares  mix  for  an  availability  of  82.4  percent,  the 
model  solution  is  to  select  two  filters,  one  valve,  and  one  sensor.  If  we  want  the  spares 
mix  for  a  resource  target  of  $8,  the  model  solution  is  to  select  two  filters  and  one 
valve.  Notice  that  the  resource  target  ($8)  is  always  greater  than  or  equal  to  the 
model  resource  expenditure  ($7)  because  the  model  buys  complete  spares.  In  general, 
the  model  expenditure  is  at  worst  a  few  percent  less  than  the  target.  The  resolution  is 
accurate  enough  given  the  range  of  uncertainties  for  the  budgets  and  spare  costs.  In 
the  next  section,  we  expand  the  model  resources  from  dollars  to  include  weight  at 
shuttle  launch  and  on-orbit  storage  volume. 

MULTIPLE  RESOURCE  OPTIMIZATION 

So  far  in  our  examples,  the  resource  is  the  unit  price  of  the  ORU.  However,  the 
model  can  handle  unit  weight,  unit  volume,  or  a  combination  of  individual  resources 


to  establish  the  limiting  resource.  When  a  combination  of  resources  is  used,  the 
model  performs  a  multiple-criteria  optimization  and  can  balance  possible  conflicting 
resource  utilization  of  spares. 

The  value  for  the  unit  resource  in  Equation  3-3  is  estimated  with  the  linear 
combination  shown  in  Equation  3-4  for  on-orbit  spares.  Equation  3-4  assumes  that 
the  user  is  interested  in  price  and  weight  for  shuttle  launching. 

unit  resource  I  =  (^coefficient  Xprice^  ^  I  —  coefficient)  X  weight  [Eq.  3-4] 

If  the  user  wishes  to  produce  a  spares  mix  for  the  minimal  total  cost 
(dollars),  the  model  sets  the  coefficient  to  1  and  ignores  the  weight  of  the  ORU. 
Conversely,  if  the  user  wishes  to  produce  a  spares  mix  for  a  minimal  total  weight,  the 
model  sets  the  coefficient  to  0  and  ignores  the  cost  of  the  ORU.  If  a  combination  of  the 
two  resources  is  desired,  the  model  uses  a  coefficient  between  0  and  1.  As  the 
coefficient  value  changes  over  this  range,  the  relative  importance  of  price  to  weight 
changes  proportionately.  Each  spares  mix  produced  in  this  way  is  optimal  in  the 
sense  that  no  other  mix  with  the  same  or  lesser  total  cost  and  the  same  or  lesser  total 
weight  achieves  the  same  or  greater  availability.  (A  modification  of  the  reasoning  in 
Appendix  A  can  be  used  to  establish  this.)  By  using  the  coefficient,  the  user  can 
perform  multi-criteria  optimization  for  two  resources. 

To  demonstrate  the  multi-criteria  optimization,  we  run  the  model  (in  the 
multiple-pass  mode)  for  11  different  passes  using  our  test  drive  data  base  and  results. 
The  example  is  for  Criticality  Code  1  ORU  only.  The  model  automatically  changes 
the  coefficients  after  each  pass,  producing  a  range  of  coefficients  (1.0,  0.9, . . .  0.2,  0.1, 
0).  For  each  pass,  the  user-specified  target  is  set  to  a  95  percent  availability. 
Exhibit  3-1  displays  the  plot  for  the  11  passes.  The  plot  is  really  composed  of 
11  points  connected  by  a  smooth  line. 

Similar  to  the  resource-versus-availability  curve,  the  plot  in  Exhibit  3-1 
describes  the  range  of  tradeoffs  between  cost  and  weight.  The  user  then  can  deter¬ 
mine  which  tradeoff  is  most  appropriate.  For  instance,  we  can  attain  a  fairly  low-cost 
solution  without  totally  sacrificing  station  weight.  The  point  near  the  elbow  of  the 
curve  in  Exhibit  3-1  offers  that  balance  and  is  the  point  the  model  selected  for  the 
spares  solution.  Increasing  the  minimal  total  cost  of  the  spares  mix  by  1  percent 
(from  $193,306  with  a  coefficient  of  1.0  to  $195,230  with  a  coefficient  of  0.5)  improves 
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Weight 

(lbs) 


ITERATIVE  PRICE  VS  WEIGHT  SOLUTIONS 
Target  Availability  =  95%  for  P^OO 


26,545 

21,236 

- 

- 

15,927 

10,618 

- 

1 _ 

5,309 

- 

- 

0 

_ 1 _ 1 

1 _ 1 _ 

0  80,703  161,406  242,109  322,812  403,515 

Price  ($K) 


J 


EXHIBIT  3-1.  RESOURCE  TRADEOFF  POSSIBILITIES  AT  95  PERCENT  AVAILABILITY 

the  total  weight  of  the  initial  spares  49  percent  (from  26,545  pounds  down  to 
13,556  pounds).  [The  Pass  Solutions  Table  (see  Chapter  8)  presents  the  actual 
numbers  that  generated  Exhibit  3-1.] 

The  model  is  actually  performing  two  types  of  tradeoffs  in  Exhibit  3-1.  One 
tradeoff  is  across  ORUs.  As  the  relative  importance  of  weight  increases,  the  model 
moves  from  selecting  ORUs  with  the  greatest  bang  for  buck  to  selecting  ORUs  with 
the  greatest  bang  for  pound.  The  other  tradeoff  is  between  on-orbit  and  ground  stock 
for  a  specific  ORU.  When  price  is  the  only  resource  of  concern,  on-orbit  spares  are 
selected  because  they  offer  a  greater  improvement  in  availability  than  ground  spares. 
As  weight  becomes  more  important,  more  groimd  spares  are  selected  because  they 
carry  no  weight  penalty. 

As  we  said  earlier,  each  point  in  Exhibit  3-1  is  an  undominated  solution, 
meaning  that  for  a  point’s  total  cost  and  weight,  no  other  spares  mix  will  produce  a 
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higher  station  availability.  Any  mix  with  higher  station  availability  will  have 
higher  cost,  higher  weight,  or  both. 

In  Exhibit  3*1,  we  showed  a  possible  model  scenario  using  price  and  weight  in 
the  ORU  tradeoff  and  a  user  availability  target  of  95  percent.  The  model  can  also 
consider,  in  the  linear  combination  for  unit  resource  (Equation  3-4),  the  addition  of  a 
third  resource  —  volume.  (With  modification,  the  model  could  include  many  more 
resources  such  as  pressurized  or  nonpressurized  weight  and  volume.)  Also,  if  the  user 
has  a  ceiling  for  station  on-orbit  storage  volume,  shuttle  lift  weight,  and  spares 
investment,  the  user  can  constrain  the  spares  mix  to  those  limits.  Chapter  7 
discusses  how  that  expansion  and  the  multiple-pass  mode  in  general  are  imple¬ 
mented. 


CHAPTER  4 


DETAILED  ORU  MULTI-ECHELON  METHODOLOGY 


In  this  chapter,  we  discuss  the  model  methodology  at  the  lowest  level,  the  ORU. 
We  start  by  discussing  the  multi-echelon  tradeofT  for  each  successive  spare  (specific¬ 
ally,  the  ORU  PSN  and  \mit  resource  used  in  Equation  3-4).  That  tradeoff  deter¬ 
mines  the  number  and  storage  location  of  the  spares  the  model  selects.  We  then 
discuss  some  M-SPARE  ORU  extensions  in  order  to  estimate  most  types  of  station 
spares  requirements.  Specifically,  we  discuss  how  M-SPARE  estimates  spares  for 
various  conditions  or  types  of  ORUs  on  the  station. 

The  first  section  of  this  chapter.  The  ORU  Multi-Echelon  Tradeoff,  is  divided 
into  the  following  subsections: 

•  An  Example  of  the  Maintenance  Process.  We  present  a  deterministic 
example  of  the  maintenance  process  and  how  the  process  affects  the  spares 
on  the  station. 

•  Probability  Distribution  of  Unserviceable  Spares.  We  move  away  from  the 
deterministic  example  and  discuss  how  to  calculate  the  probability 
distribution  for  the  number  of  unserviceable  (broken)  units  in  the  mainte¬ 
nance  process  at  the  start  of  a  cycle. 

•  Multi-Echelon  ORU  PSN.  We  describe  how  the  model  estimates  the  ORU 
PSN  given  any  combination  of  on-orbit  and  ground  stock. 

•  Multi-Echelon  Tradeoff.  We  discuss  the  spares  selection  process  between  on- 
orbit  and  ground  stock.  The  multi-echelon  tradeoff  is  similar  to  the 
marginal  analysis  technique  used  across  ORUs. 

The  second  section,  ORU  Extensions,  is  divided  into  the  following  chapter 
subsections: 

•  Replaced  Condemnations.  We  describe  how  M-SPARE  selects  spares  to 
replace  past  condemnations. 

•  Element  Launch  and  Assembly  Impacts.  We  discuss  how  the  model 
incorporates  a  growing  station  as  elements  are  added  and  ORUs  and 
quantities  increase. 
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•  Alternative  ORU  Failure  Patterns.  We  describe  how  we  approximate  differ¬ 
ent  failure  patterns  such  as  wear-related  failures. 

•  QRUs  with  Ground  Spares  Only.  We  discuss  ORUs  whose  spares  are  stored 
on  the  ground  only  and  not  on  orbit. 

THE  ORU  MULTI-ECHELON  TRADEOFF 

The  initial  focus  of  the  multi-echelon  tradeoff  is  the  maintenance  process  that 
determines  the  time  to  replace  or  repair  broken  units.  From  there,  the  model 
determines  the  number  of  broken  units  before  each  shuttle  laimch,  given  a  total 
spares  level.  Next,  the  model  determines  the  ORUs  available  (total  minus  broken)  to 
the  station.  Then,  the  model  determines  if  the  available  units  are  adequate  to  cover 
the  ORU  failures  in  the  next  logistics  cycle  (the  ORU  PSN).  Finally,  M-SPARE 
determines  the  best  location  (ground  or  on  orbit)  for  each  successive  spares  level. 
This  is  the  multi-echelon  tradeoff. 

An  Example  of  the  Maintenance  Process 

In  this  subsection,  we  describe  the  maintenance  process  and  how  it  affects  the 
spares  for  the  station.  We  provide  an  example  of  an  ORU  with  a  deterministic, 
constant  failure  rate  for  each  logistics  cycle. 

The  maintenance  process  starts  when  an  ORU  fails  on  the  station.  The  model 
assumes  that  the  ORU  is  removed  and  replaced  (if  there  is  a  spare)  and  the  failed  unit 
is  brought  back  to  Earth  on  the  next  shuttle.  Once  the  ORU  is  on  the  ground,  the 
model  assumes  it  will  face  one  of  the  three  alternative  maintenance  levels:  (1)  the 
Kennedy  Space  Center  (KSC)  will  repair  the  ORU;  (2)  the  prime  contractor  or  OEM 
will  repair  the  ORU;  or  (3)  maintenance  engineers  will  condemn  the  ORU  and  a  new 
one  will  be  procured.  If  the  repaired  ORU  or  the  replacement  unit  is  needed,  it  is  then 
ready  to  be  returned  to  the  station  on  the  next  shuttle.  [Note:  M-SPARE  does  not 
consider  delays  from  on-orbit  maintenance  in  its  availability  calculation  because  its 
impacts  on  spares  selection  are  minimal.] 

Figure  4-1  illustrates  the  deterministic  maintenance  process  over,  time  (logis¬ 
tics  cycles  of  180  days)  for  a  hypothetical  ORU.  Four  failures  of  the  ORU  initially 
occur  on  orbit  during  a  cycle.  The  failed  units  are  brought  down  to  Earth  where  none 
are  repaired  at  KSC,  three  spares  (three  quarters  of  the  failures)  are  repaired  at  the 
OEM  in  145  days  (less  than  one  logistics  cycle),  and  one  spare  (a  quarter  of  the 
failures)  is  condemned  and  a  new  spare  procured  in  26  months  (less  than  five  logistics 
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cycles).  The  user  inputs  the  fraction  of  failures  distributed  to  each  maintenance  level 
and  the  time  required  for  maintenance  at  each  level,  and  the  M-SPARE  model 
calculates  the  number  of  cycles  required  for  maintenance  (the  number  of  days  divided 
by  logistics  cycle  length).  The  number  of  maintenance  days  at  each  level  is  the  length 
of  time  a  spare  is  on  the  ground  before  it  is  ready  to  be  returned  to  orbit  on  the 
shuttle.  The  number  of  maintenance  days  includes  time  for  testing,  fault  isolation, 
administration,  transportation,  and  other  times  associated  with  the  maintenance 
process  or  shuttle  requirements. 


Orbit: 


Ground: 


Logistics  cycles: 

1 

2 

3 

4 

5 

6 

7 

Total  unserviceable 
spares  at  start  of  cycle: 

0 

4 

1 

1 

1 

1 

0 

FIG.  4-1.  MAINTENANCE  PROCESS 
(Estimating  unserviceable  ORU  spares  over  time) 

Most  inventory  models  assume  continuous  repair  and  resupply  of  spares,  but  an 
on-orbit  inventory  is  different.  When  an  ORU  fails  on  orbit,  it  must  wait  for  a  shuttle 
to  return  it  to  the  ground,  and  after  it  is  repaired  or  replaced  on  the  ground,  the  unit 
miist  wait  for  a  shuttle  to  return  it  to  the  station.  The  maintenance  plan  must 
include  those  waiting  times.  That  is  why  our  example  includes  the  time  a  broken 
spare  spends  on-orbit  in  the  first  logistics  cycle.  Furthermore,  whether  the  OEM  can 
fix  a  spare  in  45  days  or  145  days,  the  number  of  logistics  cycles  for  maintenance 
remains  the  same.  Thus,  the  key  reference  for  the  model  is  not  days,  like  other 
inventories,  but  conditions  on  the  ground  at  the  beginning  of  each  cycle  before  the 
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shuttle  launch.  (To  simplify  the  model,  we  assume  that  shuttle  launching  and 
landing  occurs  within  a  day.  The  actual  interval  is  longer  than  one  day,  but  it  is 
relatively  short  when  compared  with  the  entire  length  of  the  logistics  cycle.) 

For  our  example,  the  number  of  unserviceable  (broken)  ORUs  for 
Cycles  1  through  7  are  0,  4,  1,  1,  1,  1,  and  0,  respectively  (see  bottom  row  in 
Figure  4-1).  However,  that  example  only  traces  the  unserviceable  spares  generated 
from  one  logistics  cycle.  Figure  4-2  depicts  that  same  example  with  failures 
generated  from  many  logistics  cycles  overlaid  on  one  another.  Each  horizontal  row 
above  the  logistics  cycle  line  shows  the  number  of  unserviceable  units  generated  from 
the  same  logistics  cycle.  To  estimate  the  total  number  of  unserviceable  spares  before 
any  shuttle  launch,  we  add  the  column  of  numbers  in  Figure  4-2  to  obtain  the  bottom 
horizontal  box.  After  a  few  cycles  (start  of  cycle  6),  we  reach  steady-state  conditions. 
In  steady  state,  the  unserviceable  units  have  arisen  from  five  different  cycles:  the 
four  failures  from  the  last  logistics  cycle  (three  will  eventually  enter  repair  and  one 
will  be  replaced)  and  then  one  condemnation  from  two,  three,  four,  and  five  cycles 
earlier  (the  other  failures  from  these  cycle  were  repaired  at  the  OEM). 
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FIG.  4-2.  UNSERVICEABLE  ORU  SPARES  AT  SHUTTLE  LAUNCH 

Once  we  know  the  number  of  unserviceable  spares  at  the  beginning  of  each 
cycle,  we  then  know  the  optimal  spares  mix:  the  total  spares  we  need  and  their 
storage  location.  For  the  sixth  logistics  cycle  (the  sixth  shuttle  launch),  we  know  that 
eight  units  are  unserviceable.  We  also  know  that  for  the  next  cycle,  the  station  will 
experience  four  failures  so  it  needs  the  shuttle  to  lift  an  additional  four  spares.  Thus, 
the  station  requires  a  total  of  12  spares  (8  plus  4)  and  4  of  the  spares  stored  on  orbit. 
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As  discussed  in  Chapter  1,  the  model  estimates  net  spares  requirements  once  a 
year  at  a  shuttle  launch  occurring  one  logistics  cycle  prior  to  the  end  of  the  year.  For 
our  example  Mrith  a  logistics  cycle  of  180  days,  the  shuttle  launch  month  (LM)  is  the 
seventh  month  of  each  fiscal  year. 

Probability  Distribution  of  Unserviceable  Spares 

Station  ORUs  do  not  behave  in  a  deterministic  fashion  as  portrayed  in  our 
example.  Each  part  of  the  process  just  described  has  some  uncertainty  that  we 
approximate  with  a  probability  distribution.  For  now,  we  assume  the  on-orbit 
failures  process  is  random  for  each  ORU  so  that  the  number  of  failures  in  a  logistics 
cycle  is  described  by  a  Poisson  distribution.  (Later,  we  will  discuss  how  to  handle 
ORUs  that  are  not  characterized  by  that  random  process  such  as  items  with 
wear-related  failures.)  The  Poisson  distribution  that  estimates  the  probability  of 
variable  on-orbit  failures  for  an  ORU  in  the  next  logistics  cycle  is 


p{x\MO) 


MO^  X  exp{  -MO) 


[Eq.4-1] 


where 

X  =  0, 1, 2, . . .  failures 

MO  —  mean  number  of  orbit  failures  for  the  next  logistics  cycle 
=  A  X  T  X  QPA 


A  =  mean  failure  rate  [1/MTBF  (days)]  X  duty  cycle 
MTBF  =  mean  time  between  failures 
T  =  length  of  the  logistics  cycle  (days) 

QPA  —  quantity  per  application. 

The  model  calculates  that  probability  once  each  fiscal  year  at  the  launch  month.  In 
this  case,  the  mean  number  of  orbit  failures  from  our  previous  example  equals  four. 


Each  on-orbit  failure  from  the  original  Poisson  distribution  pattern  with  mean 
MO  has  a  probability  distribution  for  the  number  of  periods  that  will  be  required  for 
the  maintenance  process.  The  mean  of  that  distribution  is  based  upon  the  user’s 
estimate  of  the  actual  length  of  time  the  unit  will  spend  in  each  maintenance  level 
considering  all  conditions  of  the  maintenance  process.  Those  user  estimates  are 
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independent  of  the  number  or  type  of  ORUs  in  maintenance.  Given  that,  we  compute 
the  probability  distribution  for  the  total  number  of  unserviceable  or  broken,  6,  units 
in  maintenance  on  the  ground  or  “just  failed”  on  orbit. 

At  shuttle  launch,  there  are  failures  from  the  previous  logistics  cycle,  there  are 
the  failures  from  two  cycles  ago  that  are  still  in  maintenance,  there  are  failures  from 
three  cycles  ago  that  are  still  in  maintenance,  etc.  Each  of  those  cycles  has  a  Poisson 
distribution  for  unserviceable  units.  Since  the  failures  occur  in  different  cycles  and 
the  maintenance  times  are  independent,  their  probability  distributions  are  inde¬ 
pendent,  t  The  sum  of  Poisson  variables  is  Poisson  with  a  mean  equal  to  the  sum  of 
the  individual  cycle  means.  (That  mean  is  what  we  termed  the  total  unserviceable 
spares  at  launch  in  our  deterministic  example.)  Equation  4-2  gives  the  probability 
distribution  for  the  number  of  unserviceable  units  in  maintenance. 

probability  {b  unserviceables)  =  p(6  \MB)  >  4-21 


where 

b  =  0, 1, 2, . . .  unserviceable  spares 

MB  =  mean  number  of  unserviceable  units  at  shuttle  launch. 

Multi-Echelon  ORU  PSN 

Once  the  model  estimates  the  probability  distribution  for  unserviceable  spares 
for  a  particular  ORU,  it  then  estimates  the  working  spares  available  for  the  station 
and  the  ORU  PSN  (probability  of  a  spare  when  needed).  At  a  particular  launch,  the 
model  looks  back  to  determine  the  number  of  unserviceables  and  forward  to  deter¬ 
mine  what  will  fail  on  the  station  in  the  next  cycle.  When  that  is  established,  the 
model  then  calculates  the  PSN  for  each  spares  stock  level,  s,  where  s  equals  0, 1,  2,  3, 
etc.  The  level,  s,  for  the  ORU  is  composed  of  the  orbital  echelon  So  and  the  ground 
echelon  Sg  (this  is  what  we  mean  by  a  multi-echelon  stock  policy).  The  model  first 
determines  which  is  the  best  multi-echelon  stock  policy  (i.e.,  produces  the  highest 


iPalm’s  Theorem  establishes  the  fact  that  if  failures  arise  from  a  Poisson  process  and  under 
certain  other  conditions  satisfied  here,  the  number  of  units  in  resupply  is  also  Poisson  with  a  mean 
equal  to  the  product  of  the  failure  rate  and  the  mean  resupply  time.  For  example,  see  Hadley  and 
Whitin,  Analysis  of  Inventory  Systems,  Englewood  Cliffs,  N.J.:  Prentice-Hall,  1963,  p.204. 
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PSN)  for  each  stock  level.  In  other  words,  for  a  spares  level  of  3,  decides  whether 
the  best  policy  would  be  to  store  0, 1, 2,  or  3  spares  on  orbit. 

Table  4-1  presents  a  multi-echelon  example  of  the  model’s  evaluation  process 
for  which  s  equals  3  and  So  equals  2.  We  assume  we  send  up  enough  stock  on  each 
shuttle  to  restore  the  orbital  spares  stock  to  So,  if  possible.  Of  course,  on  some 
occasions  we  may  not  be  able  to  restore  the  orbital  spare  stock  to  So  because  of  the 
number  of  broken  units  of  the  ORU.  In  order  to  estimate  the  PSN  for  this  stockage 
policy,  the  model  must  consider  several  possible  combinations.  If  0  or  1  spare  is 
broken,  the  station  can  have  two  spares  on  orbit.  Thus,  enough  spares  are  available 
to  cover  0, 1,  or  2  additional  on-orbit  failures.  If  the  ORU  has  2  broken  spares,  it  can 
have  only  1  spare  on  orbit  and  can  cover  only  0  or  1  additional  failure.  If  all  3  spares 
are  broken  on  the  ground,  no  spares  are  on  orbit  and  that  ORU  can  only  operate 
through  the  entire  logistics  cycle  if  it  experiences  no  failures. 

TABLE  4-1 

MULTI-ECHELON  EVALUATION 


Current  status 

Next  cycle  on  orbit 

Possible 

Spares  on 

Failures 

broken  ORUs 

orbit 

covered 

0 

2 

2,1,0 

1 

2 

2,1,0 

2 

1 

1.0 

3 

0 

0 

Mote:  Jb=2;5=3. 


If  we  take  each  combination  just  described  and  apply  the  appropriate 
probabilities,  the  result  equals  the  ORU’s  PSN  for  a  given  So  and  Sg  (sg  =  s  —  Sq)  (see 
Equation  4-3).  The  PSN  is  the  sum  of  the  conditional  probabilities.  Each  conditional 
probability  equals  p(b}MBX  the  probability  an  ORU  is  in  a  speciHc  state,  times 
p(x}MOJ,  the  probability  an  ORU  has  adequate  spares.  Those  three  conditional 
probability  terms  in  Equation  4-3  are  depicted  by  the  rows  of  Table  4-1.  In  that  table, 
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the  first  two  horizontal  rows  depict  the  first  term  in  Equation  4-3;  the  next  row,  the 
next  term;  and  the  last  row,  the  last  term. 

PSN{ao,Sg)  =  p(b^ag\MB)  X  p(x^So\MO)\  [Eq.  4-31 

+  p(b  =  ag+l\MB)  X  p(x^ao  —  l\MO)\  ... 

+  \  p{b  =  8g+ao  \MB )  X  p{x  =  0\MO )  . 

Using  Equation  4-3,  the  model  can  estimate  an  ORU  PSN  for  any  combination 
of  on-orbit  and  ground  stock  for  the  next  logistics  cycle.  Table  4-2  lists  the  PSN  for 
different  spares  stock  combinations  using  our  previous  example  —  with  one  modifi¬ 
cation.  We  assume  a  lower,  more  realistic  average  of  0.4  instead  of  4  on-orbit  failures 
per  cycle.  The  maintenance  fractions  and  maintenance  days  remain  the  same  so  the 
mean  number  of  unserviceable  units  equals  0.8.  In  general,  an  on-orbit  spare  offers  a 
higher  level  of  protection  (a  greater  PSN)  than  a  ground  spare  because  only  an  on- 
orbit  spare  can  replace  a  broken  ORU  and  keep  a  system  operating.  However,  the 
differences  between  the  PSNs  diminish  as  the  number  of  on-orbit  and  on-ground 
spares  increases. 


TABLE  4-2 

ORU  PSN  FOR  COMBINATIONS  OF  ON-ORBIT  AND  GROUND  SPARES 


$0  -  Orbital  stock 

■ 

-  Ground  stock 

0 

1 

2 

3 

•  •  • 

0 

30.1 

54.2 

63.8 

66.4 

1 

66.2 

85.5 

91.9 

93.5 

2 

87.9 

96.3 

98.6 

99.1 

3 

96.6 

99.1 

99.7 

99.9 

4 

99.2 

99.8 

99.9 

99.9 

• 

• 

• 
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Multi-Echelon  Tradeoff 


With  the  capability  to  estimate  the  ORU  PSN  for  any  combination  of  spares,  the 
model  can  then  calculate  the  best  allocation  of  on-orbit  and  ground  spares  for  each 
spares  level.  Before  we  discuss  that  prioritization,  we  have  to  define  the  various 
resources. 


Unit  price  is  a  basic  resource  and  does  not  change  if  the  ORU  is  stored  on  orbit 
or  on  the  ground.  Station  storage  volume  is  another  resource  but  is  only  consumed 
when  spares  are  stored  on  orbit.  The  next  resource  is  the  weight  capacity  of  the 
shuttle  flights  that  transport  the  pre-positioned  spares.  Again,  only  spares  stored  on 
orbit  consume  that  resource.  Though  on-orbit  and  needed  ground  spares  require  a  lift 
into  space,  the  on-orbit  spare  actually  requires  an  additional  lift.  The  on-orbit  spares 
require  a  shuttle  lift  to  pre-position  them  on  orbit  and  a  lift  to  replenish  the  inventory 
after  a  failure.  Ground  spares  only  require  one  lift  to  replace  a  failure. 

The  model  starts  the  multi-echelon  tradeoff  process  by  developing  a  beneflt-to- 
unit  resource  ratio  in  order  to  choose  the  spare  location  with  the  largest  ratio.  The 
process  is  similar  to  the  method  discussed  earlier  for  setting  priorities  for  spares 
across  all  ORUs.  The  next  two  equations  extend  the  general  ratio  equation 
(Equation  3-3)  to  treat  on-orbit  and  ground  spares: 

On-orbit  spares: 


marginal  benefit  ln\  PSN{so+l,Sg)^  — /n[PSAr(so,  s^)] 

unit  resource  (coefficient  X  price)  +  \{\~  coefficient)  X  weight] 


[Eq.  4-4] 


Ground  spares: 

marginal  benefit  _  /«[PSiV(so,  s^+1)]  —  /n[PSiV(so,  s^)| 
unit  resource  (coefficient  X  price) 


[Eq.  4-5] 


Thus,  if  the  user  ignores  an  ORU’s  weight  (i.e.,  makes  the  coefficient  equal  1  for 
all  ORUs),  the  model  will  select  an  on-orbit  spare  over  a  ground  spare.  That  effect  is 
illustrated  in  Table  4-2,  in  which  the  on-orbit  spare  always  produces  a  higher  PSN 
than  the  ground  spare  for  the  same  unit  cost.  In  Table  4-3,  we  take  the  same 
example,  but  consider  cost  and  weight  equally  (coefficient  =  0.5)  and  assume  the 
ORU  costs  $1.00  and  weighs  one  pound.  The  multi-echelon  tradeoff  selection  process 
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starts  by  choosing  a  ground  spare  (highest  ratio)  and  ends  up  selecting  four  out  of 
seven  on-orbit  spares.  If  weight  is  given  a  greater  importance  (i.e.,  the  coefficient 
decreases)  the  model  selects  the  ground  spares  with  more  frequency. 


TABLE  4-3 

ORU  MULTI-ECHELON  TRADEOFFS 


Spares  selection 

Resource 
($0.5  +  0.51b) 

PSN 

BenefK/ 
resource  ratio 

Total 

On  orbit 

Ground 

0 

0 

0 

0 

30.1 

.... 

1 

0 

1 

0.5 

54.2 

1.17562 

2 

1 

1 

1.5 

85.5 

0.45604 

3 

1 

2 

2.0 

91.9 

0.14487 

4 

2 

2 

3.0 

98.6 

0.06982 

5 

3 

2 

4.0 

99.7 

0.01184 

6 

3 

3 

4.5 

99.9 

0.00225 

7 

4 

3 

5.5 

99.9 

0.00088 

The  model  implements  its  methodology  by  first  producing  the  last  column  in 
Table  4-3  for  every  ORU.  Then,  at  each  stage  of  the  selection  process,  it  looks  across 
all  ORUs  and  picks  the  ORU  whose  top  spare  has  the  greatest  benefit/resource  ratio. 
The  model  then  moves  on  down  the  ratio  column  of  the  selected  ORU  and  repeats  the 
process.  The  imit  resource  part  of  Equations  4-4  and  4-5  can  be  further  extended  to 
handle  more  resources  (e.g.,  on-orbit  volume). 

ORU  EXTENSIONS 

In  this  section,  we  will  discuss  some  of  the  model  extensions  that  enable 
M-SPARE  to  estimate  most  of  the  station’s  spares  requirements,  including  the 
follovang; 

•  Modeling  future  replacement  of  condemnations 

•  Station  growth  as  elements  are  launched  and  assembled 
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•  Alternative  ORU  failure  patterns 

•  An  alternative  spares  storage  strategy. 

Replaced  Condemnations 

The  M-SPARE  methodology  mentioned  above  uses  a  repair  philosophy  to 
estimate  unserviceables.  The  model  assumes  that  after  a  speciHed  time,  mainte¬ 
nance  generates  a  serviceable  ORU.  A  condemnation  also  undergoes  a  maintenance 
time,  but  unlike  a  repair,  its  “maintenance”  is  actually  the  prociu’ement  of  a  new 
ORU.  In  this  subsection,  we  discuss  how  M-SPARE  incorporates  a  procurement  for  a 
replaced  condemnation  into  its  general  repair  philosophy. 

To  illustrate  that  point,  we  return  to  our  general  example  in  Chapter  1  and 
compare  it  to  our  example  in  the  previous  section  depicting  the  M-SPARE 
methodology  (both  examples  use  identical  deterministic  failures  rates  and 
maintenance  times  and  are  displayed  in  Table  4-4).  The  general  approach  estimates 
spares  requirements  by  subtracting  cumulative  repairs  from  cumulative  failiu’es. 
The  difference  equals  the  spares  required  to  cover  the  number  of  failures  that  remain 
broken  at  the  beginning  of  a  logistics  cycle  (top  of  Table  4-4).  That  is  similar  to  our 
example  in  the  previous  section  (bottom  of  Table  4-4).  For  that  example,  we  directly 
estimated  the  number  of  unserviceables  (items  that  remain  broken)  at  the  beginning 
of  a  cycle  and  add  that  to  the  orbit  failures  for  the  next  cycle  to  estimate  spares 
requirements.  Notice  that  the  requirements/LC  for  the  general  approach  is  identical 
to  the  gross  requirements/LC  in  our  M-SPARE  methodology,  except  for  FY99.  That 
difference  is  because  M-SPAiiE  thinks  that  maintenance  process  has  had  enough 
time  to  replace  the  earlier  condemnations.  In  Table  4-4,  those  replaced  condem¬ 
nations  equals  cumulative  condemnations  minus  ORUs  in  procurement. 

The  M-SPARE  model  incorporates  replaced  condemnations  by  decreasing  assets 
from  the  previous  year  by  the  amount  equal  to  the  replaced  condemnations.  To 
calculate  the  assets  for  FY99  (bottom  of  Table  4-4),  M-SPARE  takes  the  previous 
year’s  requirements  (12)  minus  the  replaced  condemnations  in  FY99  (2)  to  obtain  a 
current  asset  level  (10).  Now,  when  the  reduced  assets  are  subtracted  from  gross 
requirements/year,  the  net  requirement  equals  2  (12  — 10).  'Thus,  the  net  require¬ 
ment  for  the  M-SPARE  implementation  and  the  general  approach  are  equal  (two 
shaded  rows).  In  that  way,  the  net  and  gross  requirements  reflect  the  desired  spares 
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TABLE  4^ 


SPARES  REQUIREMENTS 
(DETERMINISTIC  FAILURES) 


General  approach: 

Failures/LogCycle 
Cumulative  failures 
Cumulative  repaired 


Requirements/LogCycle 
Req  ui  rements/yea  r 
Previous  assets 


lii«trequirem«nt$ 


M-SPARE  methodology: 
Next  orbit  failures 
Broken  ORUs 


Gross  requirements/LogCycle 
Broken  ORUs 
ORUs  in  repair 
ORUs  in  procurement 
Cumulative  condemnation 


Replaced  condemnations 
Gross  Requirements/year 
Previous  assets 
Replaced  condemnations 

Netrequlremems 


3 

D 

4 

4 

12 

16 

3 

6 

9 

10 

10 

8 

2 

4 

4 

5 

6 

9 

10 

3 

3 

2 

3 

2 

3 
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quantities.  The  net  spares  requirements  include  replacements  for  condemnations  so 
that  NASA  can  order  and  budget  for  the  proper  number  of  spares. 

Another  point  is  that  when  the  model  reduces  assets  by  the  number  of  replaced 
condemnations,  it  does  not  reduce  M-SPARE  dollar  values.  For  instance,  the 
accumulated  spares  investment  used  for  the  resource-versus-availability  curve  still 
includes  the  cost  to  replace  condemnations.  In  that  way,  spares  investment  and  the 
budget  estimates  are  consistent. 

Element  Launch  and  Assembly  Impacts 

The  M-SPARE  model  methodology  also  incorporates  failure  rates  that  vary  over 
time  due  to  element  launches  or  “mission  builds”  (the  construction  phases  of  the 
space  station).  At  any  point  in  time,  the  M-SPARE  failure  rate  equals  the  ORU’s 
duty  cycle,  multiplied  by  the  quantity  per  application  (QPA),  multiplied  by  the 
logistics  cycle,  and  divided  by  the  mean  time  between  failures  (MTBF),  A  particular 
ORU  may  have  applications  that  are  launched  at  different  times.  With  the  increase 
in  the  number  of  applications  on  the  station,  the  ORUs  total  failure  rate  should 
increase  (the  model  holds  duty  cycle,  logistics  cycle,  and  MTBF  constant  over  time). 
M-SPARE  uses  a  monthly  QPA  profile  to  estimate  changing  failure  rates.  The  model 
generates  a  profile  from  the  element  launch  schedule  (see  Chapter  6,  Model  Options) 
and  from  the  number  of  ORU  applications  on  each  element  (see  Chapter  5,  Model 
ORU  Input  Data). 

Exhibit  4-1  displays  the  key  variables  the  model  uses  to  determine  spares 
requirements  and  expands  on  our  earlier  example  (the  tables  in  that  exhibit 
constitute  the  reports  M-SPARE  generates  —  see  Chapter  8,  Model  Outputs).  The 
example  assumes  the  MTBF  is  2,160  hours,  the  duty  cycle  is  1,  and  the  QPA  is  2  for 
each  of  3  elements.  The  element  launches  are  in  Month  1  of  FY96,  Month  1  of  FYOO, 
and  Month  7  of  FYOl  (the  top  part  of  the  exhibit).  Next,  the  exhibit  presents  the  total 
QPA  profile  by  month  for  10  years.  Notice  how  the  total  QPA  increases  at  each 
element  laimch  month.  The  middle  part  of  Exhibit  4-1  displays  the  QPA  for  each 
element  and  lists  the  element  launch  schedule  in  calendar  and  fiscal  months  and 
years. 
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Schedule  ••••••••• 

Element  # 

CalendanMth 

Year  |  Fiscal :Mth 

FY 

1  LabA 

10 

1995  1 

1996 

2  HabA 

10 

1999  1 

2000 

3  PLM3 

4 

2001  7 

2001 

ORU#  1  EXAMPLE  STATION  ORU 
QPA  BY  MONTH  (COL).  YEARS  (ROW) 

1  2  3  4  5  6  7 


LogCyc1«>  180  NOT  a  wear  Item 


8  9  10  11  12 


1996 

1997 

1998 

1999 

2000 
2001 
2002 

2003 

2004 

2005 


Element  4*  12  3 

Element  QPA  2  2  2 


AT 

ORU  1  EXAMPLE 

STATION 

ORU 

lei  YR 

Mean  Orbit  Mcar 

1  Broken 

Replace  Condemn. 

VMR 

1996 

4.00 

4.00 

0.00 

1.00 

1997 

4.00 

6.00 

0.00 

1.00 

1998 

4.00 

8.00 

0.00 

1.00 

1999 

4.00 

8.00 

2.00 

1.00 

2000 

8.00 

12.00 

2.00 

1.00 

2001 

12.00 

14.00 

2.00 

1.00 

2002 

12.00 

21.00 

2.00 

1.00 

2003 

12.00 

23.00 

4.00 

1.00 

2004 

12.00 

24.00 

5.00 

1.00 

2005 

12.00 

24.00 

6.00 

1.00 

EXHIBIT  4-1.  EXAMPLE  STATION  ORU 


In  FY96  to  FY99,  the  entries  for  the  mean  on  orbit,  mean  broken,  and  replaced 
condemi  tions  at  the  bottom  of  Exhibit  4-1  matches  our  previous  example  in 
Table  4-4.  In  FYOO,  the  QPA  increEises  causing  expected  failures  and  other  variables 
to  increase  as  well. 

As  discussed  in  Chapter  1,  the  model  estimates  net  spares  requirements  once 
each  year  at  a  shuttle  launch.  That  launch  occurs  a  logistics  cycle  from  the  end  of  the 
year.  For  our  example,  with  a  logistics  cycle  of  180  days,  the  shuttle  launch  month 
(LM)  is  the  seventh  month  each  fiscal  yesur.  At  that  time,  the  model  looks  back  to 
determine  the  number  of  unserviceables  units  and  forward  to  determine  what  is 
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expected  to  fail  on  the  station  in  the  next  cycle.  The  bottom  part  of  Exhibit  4-1 
presents  the  key  M-SPARE  variables  at  the  yearly  laimch  month  for  mean  orbit 
failures,  mean  broken  ORUs,  and  replaced  condemnations.  We  will  now  present  the 
equations  for  each  of  these  variables  and  then  present  the  equation  variable 
definitions. 

In  Equation  4-6,  the  model  estimates  mean  broken  (MB),  ORUs  for  each  model 
year  by  summing  the  fraction  of  the  total  failures  that  occurred  for  each  component 
(KSC,  prime/OEM,  and  condemnations)  one  maintenance  time  earlier  (see  Equation 
4-7).  Maintenance  time  equals  a  logistics  cycle  for  broken  ORUs  still  on-orbit  plus 
the  number  of  complete  logistics  cycles  in  the  repair/procurement  time. 

3 

MBiyr)  =  B, ,  [Eq.  4-61 

Z=l 


LUiyr)- 1 

Bj^r)  =  \  X  F,  X  2  QPA(m) .  [Eq.  4-7] 

m  =  LMiyr)  —  MMi 

The  equation  to  estimate  mean  orbit,  MO,  failures  for  the  next  logistic  cycle 
(i.e.,  from  the  launch  month  to  the  end  of  the  fiscal  year)  for  a  given  model  year  is  the 
following: 


LUiyr)+MLC-l 

MCXyr)  =  A  X  QPA(m).  [Eq.  4-8] 

m^LMlyri 

As  discussed  in  Table  4-4,  the  model  estimates  the  number  of  replaced 
condemnations  by  first  subtracting  the  condemnation  component  of  the  mean  number 
of  broken  ORUs  [B3(yr)]  from  the  total  condemnations  since  the  first  month  of  the 
first  model  year.  That  integer  value  is  the  cumulative  number  of  replaced 
condemnations  [Ci2C(yr)]  (see  Equation  4-9).  Next,  the  model  takes  the  projected 
difference  in  CRC  for  successive  years  to  obtain  the  incremental  number  of  replaced 
condemnations  [/2C(yr)]  for  a  specific  model  year  (see  Equation  4-10). 


CRCiyr) 


LMiyr)~l 

A  X  P3  X  S  QPMm) 

W=1 


-Bsiyr^ 


[Eq.  4-91 
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RC[yr)  =  CRCiyr)  -  CRCiyr  -  1), 


[Eq.  4-10] 


where 

X 


QPA(m) 

I 

F 

MM 

NLC 


[] 

MLC 


LM(yr) 

yr 

RC 

CRC 


mean  orbit  failures  per  month 


duty  cycle  X  720  (hours/ months) 
MTBFihours) 


1,2...  (year  X  12)  where  the  year  is  the  number  of  model  years 
the  user  specifies  (see  Chapter  6) 

sum  of  all  elements  QPA  launched  by  month  m 

maintenance  levels  ( 1  =  KSC,  2 = prime/OEM,  3 = condemnations) 

fraction  of  total  failures  entering  each  maintenance  level 

maintenance  months  =  NLCxMLC 

number  of  logistics  cycles  in  the  entire  maintenance  time 


Lt 


LogCycle  (days)-^  repair  or  replace  (days) 


LogCycle  (days) 


I 


for  value  in  brackets,  take  the  largest  integer  value,  i.e.,  truncate 

real  number  into  a  integer  value 

months  in  a  LogCycle 

LogCycle  (days) 

30  (days!  month) 

launch  month,  calculation  point  of  spares  requirements,  assumes 
that  it  is  one  LogCycle  from  end  of  fiscal  year 

(yr  X  12)  —  MLC  + 1 

model  year 

replaced  condemnations 
cumulative  replaced  condemnations. 
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Alternative  ORU  Failure  Patterns 

Typically,  component  failures  are  assumed  to  follow  a  Poisson  distribution 
pattern.  However,  certain  ORUs  may  exhibit  different  failure  (demand)  patterns 
that  are  not  typical.  M-SPARE  uses  two  additional  probability  distributions  to 
approximate  the  range  of  possible  demand  patterns.  The  actual  distribution  used  by 
the  model  is  determined  on  the  basis  of  the  variance-to-mean  ratio  (VMR)  of  the 
demand  for  ORUs  and  is  an  input  to  the  model  (see  Chapter  5)  or  determined  by  the 
simulation  (see  Chapter  10).  The  ORU  VMR  is  a  measure  of  demand  uncertainty. 
Larger  VMRs  translate  into  higher  spares  requirements.  In  most  cases,  the  ORU 
VMR  is  assumed  to  be  1  and  the  model  uses  the  Poisson  distribution.  If  the  ORU 
VMR  is  less  than  1,  the  model  uses  the  binomial  distribution  method  to  approximate 
the  demand  pattern.  This  method  is  usually  used  for  wear-related  demands  that  are 
more  predictable  than  the  typical  demand  pattern  for  random  failures.  In  those 
cases,  the  simulation  automatically  calculates  the  VMR.  If  the  ORU  VMR  is  greater 
than  1,  the  model  uses  the  negative  binomial  distribution  method  to  approximate  the 
demand  pattern.  That  is  usually  the  case  for  ORUs  with  suspect  data  quality, 
drifting  demand  levels,  or  greater  demand  uncertainty  than  the  typical  ORU. 

When  the  VMR  is  less  than  or  greater  than  1,  the  model  replaces  the  Poisson 
distribution  assumed  in  Equations  4-1, 4-2,  and  4-3  with  the  appropriate  distribution. 
However,  the  basic  methodology  remains  the  same. 

Table  4-5  is  an  example  of  different  distributions  with  a  mean  demand  of  0.4  but 
a  VMR  of  0.6,  1,  and  3.  The  number  of  spares  required  to  obtain  a  cumulative 
probability  of  0.999  (an  indicator  of  ORU  spares  protection)  equals  1,  3,  and  9, 
respectively.  In  other  words,  when  all  else  is  equal,  the  model  shifts  more  spares  to 
the  ORUs  with  greater  demand  uncertainty  (larger  VMRs).  [Note:  Since  the 
binomial  distribution  method  requires  certain  parameters  to  be  integer  values,  the 
input  VMR  is  automatically  adjusted  to  meet  that  requirement.] 

Preventive  Maintenance 

The  model  also  uses  the  VMR  to  estimate  spares  requirements  for  another  ORU 
extension,  preventive  maintenance  (PM)  or  scheduled  maintenance  ORUs. 
M-SPARE  calculates  spares  requirements  for  preventive  maintenance  actions  using 
the  wear  preprocessor.  The  user  must  enter  the  annual  scheduled  replacement 
(“change-out”)  frequency  into  the  MSPAREIN.RPT  file  in  the  wear  “Life”  field  and 
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TABLE  4.S 


COMPARISON  OF  DEMAND  DISTRIBUTIONS 


Spares 

Binomial 

VMR  -  0.6 

Mean  ■  0.4 

Poisson 

VMR  -  1 

Mean  ■  0.4 

Negative  binomial 
VMR  -  3 

Mean  ■  0.4 

Probability 

Cumulativo 

Probability 

Cumulativa 

Probability 

Cumulativa 

0 

0.60 

0.60 

Bi 

MM 

1 

0.40 

1.00 

mM 

mm 

2 

0.054 

0.043 

119 

3 

0.007 

0.999 

0.021 

msM 

4 

0.011 

0.985 

5 

0.006 

0.991 

6 

0.995 

7 

0.002 

0.997 

8 

0.001 

0.998 

9 

0.001 

0.999 

then  run  the  wear  preprocessor.  The  preprocessor  calculates  the  combined  failure 
rate  from  wear-related  failures  (PM)  and  random  failures  as  described  in  Chapter  10. 
In  the  default  mode,  the  wear  preprocessor  determines  the  uncertainty  on  the  basis  of 
the  replacement  frequency.  For  instance,  a  monthly,  quarterly,  semiannual,  or 
annual  replacement  frequency  generates  VMKs  of  0.1, 0.7, 0.9,  and  1.0,  respectively. 
Greater  VMRs  translate  into  greater  M-SPARE  spares  requirements  above  the  mean 
number  required  for  the  replacements.  Since  most  scheduled  replacements  occur 
with  a  high  degree  of  certainty,  the  user  can  override  the  wear  preprocessor  by 
inserting  a  0.01  in  the  MSPAREIN.RPT  file  for  the  ORU’s  VMR.  As  a  result, 
M-SPARE  will  select  only  enough  spares  to  cover  the  mean  replacements  plus  one 
extra  spare  for  the  ground  inventory  and  one  extra  spare  for  the  orbit  (if  appropriate) 
inventory. 

ORUs  with  Ground  Spares  Only 

Next,  we  discuss  those  ORUs  whose  spares  are  only  stored  on  the  ground,  such 
as  noncritical  ORUs  (Criticality  Code  2  or  3)  or  critical  ORUs  when  on-orbit  storage 
is  not  available.  With  no  on-orbit  spares,  the  ORU  PSN  is  very  low.  It  may  cause  the 
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station  availability  to  drop  below  1  percent.  A  more  meaningful  measure  is  the 
probability  that  the  ground  inventory  fully  supplies  spares  needed  to  replace  the 
previous  cycle’s  on-orbit  failures.  We  term  that  ground  availability.  The  equation  for 
ground  availability  (Equation  4-11)  is  similar  to  the  equation  for  station  availability 
(Equation  3-1).  The  difference  is  that  for  ground  availability,  the  on  orbit  component 
of  the  PSN  (Equation  4-3)  drops  out  leaving  only  the  pib)  distribution  for 
unserviceable  (broken)  units  in  maintenance. 

ground  availability  =  H  p(bSsgi\MB  ).  [Eq.  4-11] 

oat;.  ' 

Use  of  the  ground  availability  measure  does  not  affect  the  spares  selection 
process.  The  only  difference  is  that  the  PSN  and  availability  is  strictly  a  measure  of 
ground  performance.  In  Chapter  7,  we  discuss  an  operation  mode  in  which  all  ORU 
spares  are  stored  on  the  ground. 
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CHAPTER  5 


MODEL  ORU  INPUT  DATA 


Initially,  the  most  difficult  part  of  the  model  processing  is  the  creation  of  the 
input  file  (MSPAREIN.RPT).  That  file  defines  all  the  ORUs  and  their  characteristics 
(unit  cost,  demand,  repair  times,  weight,  etc.).  This  input  drives  the  M-SPARE 
model.  If  you  wish  the  model  to  produce  an  optimal  spares  mix  for  your  particular 
distributed  system  or  subsystem,  your  data  base  should  contain  the  ORUs  of  only 
that  group. 

INPUT  FILE  DESCRIPTION 

The  input  file  is  in  an  ASCII  text  format  to  allow  browsing  or  editing  with 
standard  PC  editors.  [Note:  Always  save  input  files  in  an  ASCII  or  print  format.] 
Examples  of  the  data  file  headings  and  a  few  ORUs  from  the  sample  data  base  are 
presented  in  Exhibit  5*1.  The  file  columns  are  divided  into  five  sections.  In  the 
following  subsections,  we  define  the  data  fields  of  each  section,  list  the  type  of  field  in 
parentheses,  and  discuss  how  the  data  are  used  in  the  model. 

Description 

The  data  fields  of  this  section  are  the  following: 

•  NAME  —  a  32-character  ORU  name  (character  field). 

•  PART  NUMBER  —  an  18-character  part  identification  number  (character 
field). 

•  CAGE^  —  a  6-character  number  representing  Commercial  and  Government 
Entity  (CAGE)  codes  or  the  Federal  Supplier  Code  for  Manufacturers 
(FSCM)  (character  field). 

•  CT  —  a  2-character  criticality  code  (e.g.,  IR,  1,  IS,  and  3)  used  in  M-SPARE 
to  segregate  different  types  of  ORUs.  The  model  only  optimizes  one 
criticality  code  at  a  time  and  assumes  all  ORUs  with  the  same  criticality 
have  equal  importance  (character  field). 

•  DIST  SYSTEM  —  a  7-character  distributed  system  name.  The  name  allows 
the  model  to  further  break  down  model  outputs  to  a  distributed  system  level. 
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If  the  data  base  contains  ORUs  for  a  specific  distributed  system  only,  this 
field  can  be  used  to  report  results  at  a  subsystem  level  (character  field). 


The  model  uses  the  name,  part  number,  ai^d  CAGE  number  data  fields  for  reporting 
purposes  only.  Thus,  the  fields  can  contain  whatever  you  need  to  uniquely  identify 
the  ORU  (see  Exhibit  5-1). 

Unit  Resources 

The  data  fields  of  this  section  are  the  following: 

•  PRICE  ($K)  —  the  unit  price  of  the  ORU  in  thousands  of  dollars.  The  model 
assumes  that  all  unit  prices  are  a4justed  to  the  same  baseline  year  (real 
value  >  0). 

•  WEIGHT  (LBS)  —  the  unit  weight  of  the  ORU  in  pounds  (real  value  >  0). 

•  VOLUME  (INCH  "3)  —  the  unit  volume  of  the  ORU  in  cubic  inches  (real 
value  >  0). 

Miscellaneous 

The  data  fields  of  this  section  are  the  following; 

o  MIN.SPR  —  a  value  that  allows  the  user  some  flexibility  in  determining 
how  the  model  selects  spares.  Values  greater  than  0  force  the  model  to  buy 
at  least  the  number  of  spares  specified  (see  Chapter  6  for  information  on 
alternative  ways  of  setting  starting  asset  levels).  (Integer  value  2  0.) 

•  P/U  1/0  —  a  value  of  0, 1,  or  2  allows  the  user  to  specify  whether  the  ORU 
requires  an  unpressurized,  pressurized,  or  either  environment,  respectively 
(integer  value  of  0, 1,  or  2). 

•  PLT  —  a  value  that  determines  the  dollar  "spread”  vector  used  in 
allocating  budget  dollars  over  PLT.  The  vectors  associated  with  the  PLT  $S 
value  (e.g.,  1,  2,  3 . .  )  are  stored  in  the  OPTIONS.RPT  file  (see  Chapter  6). 
For  instance,  a  PLT  $S  value  of  1  may  correspond  to  a  vector  in  the 
OPnONS.RI^  file  of  0.0,  0.85,  0.10,  and  0.05.  That  vector  implies  that  an 
ORU  with  a  unit  price  of  $100,000  requires  $5,000,  $10,000,  and  $85,000  in 
the  first,  second,  and  third  year  of  PLT  respectively,  and  $0  in  the  delivery 
year  (integer  value  >  0). 

Maintenance  Factors 

The  data  in  this  section  are  further  subdivided  into  two  types  of  fields,  each  type 
having  three  choices  (i.e.,  three  maintenance  levels).  Level  1  represents  activities  at 
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May  3 1 . 1 992  M-SPAR  £  ORU  INPUT 

NOTE;  COSTS  ARE  NX 


DESCRIPTION _ J _ _ 1 


NAME 

PART  NUMBER 

CAGE#CT 

DIST 

SYSTEM 

PRICE 

(SX) 

WEIGHT 

(LBS) 

VOLUME 
(INCH  *3) 

MIN. 

SPR 

PARABOLIC  ANTENNA 

1234S678901234S67 

123456 

1 

1234567 

20B5 

409 

8640 

1 

transmitter-receiver 

xxxxxxxxxxxxxxx 

YYYYY 

1 

6 

614 

65 

1728 

1 

ANTENNA  CONTROLLER 

xxxxxxxxxxxxxxx 

YYYYY 

1 

6 

37S 

51 

1728 

1 

SGS  IF  SWITCH 

xxxxxxxxxxxxxxx 

YYYYY 

1 

6 

128 

25 

27 

1 

HIGH  RATE  MODEM 

xxxxxxxxxxxxxxx 

YYYYY 

1 

6 

1125 

37 

2280 

1 

HIGH  RATE  FRAME  MUX 

xxxxxxxxxxxxxxx 

YYYYY 

1 

6 

1875 

92 

3420 

1 

BASEBAND  SIGNAL  PROC 

xxxxxxxxxxxxxxx 

YYYYY 

1 

6 

1050 

77 

3420 

1 

VIDEO  BASEBAND  PROCE 

xxxxxxxxxxxxxxx 

YYYYY 

1 

6 

242 

59 

2280 

1 

lEA  STRUCTURE  A 

xxxxxxxxxxxxxxx 

YYYYY 

1 

12 

1517 

25 

4385550 

1 

lEA  TRANSITION 

xxxxxxxxxxxxxxx 

YYYYY 

3 

12 

35 

32 

864 

0 

lEAELECJUNCTI 

xxxxxxxxxxxxxxx 

YYYYY 

3 

12 

49 

42 

1728 

0 

TCS  DEPLOY  RADI 

xxxxxxxxxxxxxxx 

YYYYY 

3 

12 

1046 

658 

491400 

0 

TCSUTL  PLATTT 

xxxxxxxxxxxxxxx 

YYYYY 

3 

12 

180 

334 

1728 

0 

TCS  UTLPLATT2 

xxxxxxxxxxxxxxx 

YYYYY 

3 

12 

180 

299 

1728 

0 

EXHIBIT  5-1.  EXAMPLE  ( 


1 


°UT  DATA 
MODIFIED 


(KSC  =  1 ,  OEM  -  2.  CONDEMN  -  3) 

_MISC _ 1_- Jd^INTEN ANCJ_FACTORS_ _J _ SL^AND  FACTORS 


IN. 

3R 

P/U 

I'O 

PUT 

ss 

DAYS 

1  2 

Mths 

3 

FRAaiON 

1  2  3 

Log  DUTY 

Cyc  CYCLE 

LIFE  MTBF(HR) 
(YR)  PER  UNIT 

1 

2 

QPA  by  FY 

3  4  5 

6 

7 

' 

1 

1 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

68215 

1 

4 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

1 

135 

1 

1 

30 

18169 

2 

4 

4 

4 

4 

4 

4 

1 

1 

1 

0 

160 

8 

0 

9 

.1 

135 

1 

1 

30 

91387 

2 

4 

4 

4 

4 

4 

4 

1 

1 

1 

0 

160 

8 

0 

.9 

.'1 

135 

1 

1 

30 

113454 

1 

2 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

55071 

1 

2 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

18847 

1 

2 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

,1 

135 

1 

1 

30 

13207 

1 

2 

2 

2 

2 

2 

2 

1 

1 

1 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

38000 

1 

2 

2 

2 

2 

2 

2 

1 

1 

2 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

525600 

2 

4 

4 

4 

4 

4 

4 

0 

1 

2 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

260610 

2 

4 

4 

4 

4 

4 

4 

0 

1 

2 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

164250 

2 

4 

4 

4 

4 

4 

4 

0 

1 

2 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

42340 

2 

4 

4 

4 

4 

4 

4 

0 

1 

2 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

45260 

4 

8 

8 

8 

8 

8 

8 

0 

1 

2 

0 

160 

8 

0 

.9 

.1 

135 

1 

1 

30 

49640 

12 

24 

24 

24 

24 

24 

24 

LE  OF  ORU  DATA  BASE 


0^ 
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the  repair  facilities  of  KSC,  Level  2  represents  activities  at  the  prime  contractor  or 
OEM,  and  Level  3  represents  condemnation  of  an  ORU  and  its  replacement. 

For  each  level,  the  file  contains  DAYS  or  months  (Mths)  fields  that  specify  the 
time  required  to  repair  or  replace  an  ORU  and  FRACTION  fields  that  specify  the 
expected  fraction  of  ORUs  e  itering  the  level.  The  sum  of  the  fractions  for  the  three 
levels  should  equal  1.  If  an  ORU  has  no  repair  at  a  level,  enter  “0”  for  its  fraction. 
The  specific  fields  are  the  following; 

•  DAYS  1  —  the  repair  time  in  days  for  ORUs  being  repaired  at  KSC  (real 
value  >  0). 

•  DAYS  2  —  the  repair  time  in  days  for  ORUs  being  repaired  at  the  prime 
contractor  or  OEM  (real  value  s  0). 

•  Mths  3  —  the  PLT  in  months  to  replace  a  condemned  ORU  (real  value  >  0). 

•  FRACTION  1  —  the  fraction  of  broken  ORUs  that  are  repaired  at  the  KSC 
(real  value  s  0). 

•  FRACTION  2  —  the  fraction  of  broken  ORUs  that  are  repaired  at  the  prime 
contractor  or  OEM  (real  value  s  0). 

•  FRACTION  3  -  the  fraction  of  broken  ORUs  that  are  condemned  (real 
value  >  0). 

As  discussed  in  Chapter  4,  the  maintenance  times  and  fractions  determine  the 
mean  number  of  unserviceable  spares  that  remain  from  one  or  several  previous 
logistics  cycles.  As  KSC  facilities  repair  a  larger  fraction  of  the  broken  ORUs,  the 
shorter  repair  times  will  translate  into  fewer  spares  requirements. 

Demand  Factors 

The  data  fields  of  this  section  are  the  following: 

•  Log  Cyc  —  the  logistics  resupply  cycle  or  time  in  days  between  shuttle 
flights.  That  value  is  used  to  estimate  the  number  of  anticipated  failures 
over  the  next  cycle  and  the  number  of  cycles  required  to  repair  or  replace  an 
unserviceable  item.  While  the  logistics  cycle  can  be  assumed  as  any  number 
of  days  (e.g.,  90, 135,  180, . . . ),  the  value  remains  constant  for  each  model 
run.  The  O^IONS.RPT  file  also  contains  a  logistics  cycle  delta  value  that 
you  can  use  to  increase  or  decrease  all  ORU  logistics  cycles  (real  value  >  0). 
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•  DUTY  CYCLE  ~  the  fraction  of  time  the  ORU  will  operate  over  the  course 
of  a  year.  This  field  might  also  contain  the  product  of  the  duty  cycle  and  a 
demand  multiplier  (real  value  >  0). 

•  VMR  —  the  VMR  measures  demand  uncertainty.  Larger  VMRs  represent 
greater  demand  uncertainty  and  translate  into  higher  spares  requirements 
in  the  model.  A  VMR  of  1.0  reflects  the  assumption  of  a  Poisson  demand 
process.  ORUs  that  wear  out  (have  an  expected  lifetime)  can  have  a  VMR 
less  than  1.0  (see  Chapter  10).  Conversely,  ORUs  whose  data  quality  is 
suspect  can  have  a  VMR  greater  than  1.0  (real  value  >  0). 

•  LIFE  (YR)  -  the  mean  “wear  life”  or  “life  limits”  of  an  ORU  in  years. 
Besides  random  failures  estimated  by  the  MTBF,  the  mean  life  addresses 
failures  caused  by  wear-related  factors  or  preventive  maintenance. 
M-SPARE  estimates  those  time-related  failures  with  a  simulation 
preprocessor  (see  Chapter  10)  (real  value  >  0). 

•  MTBF  (HR)  PER  UNIT  —  the  MTBF  in  hours  per  unit  or  application  (real 
value  >  0). 

•  QPA  by  FY  —  the  QPA  or  the  total  number  of  a  specific  ORU  type  on  the 
station.  The  QPA  input  is  actually  a  number  of  fields  and  uses  two  possible 
formats:  cumulative  QPA  by  fiscal  year  or  QPA  by  element  based  upon  the 
element  launch  schedule  (mission  build).  If  you  choose  QPA  by  fiscal  year, 
the  first  QPA  column  (QPA  1)  is  the  quantity  assumed  throughout  the  fiscal 
year  for  the  first  model  year  run;  the  next  column  (QPA  2)  is  the  quantity 
assumed  for  the  second  model  year;  and  so  on.  Quantities  of  0  are  accept¬ 
able.  If  you  choose  to  express  QPA  by  element,  then  the  first  column  is  the 
QPA  for  one  element  (e.g.,  Laboratory  A),  the  second  column  is  the  QPA  for 
another  element  (Node  1),  and  so  on.  The  model  then  converts  the  QPA  by 
element  into  a  cumulative  QPA  by  fiscal  year  given  the  element  launch 
schedule  defined  in  the  OPTIONS.RPT  file  (see  Chapter  6)  (integer  value 
>0). 

The  model  uses  those  demand  factors  to  obtain  the  demands  per  logistics  cycle. 
Demand  value  is  the  driver  of  the  M-SPARE  model  and  is  derived  with  Equation  4-8. 

Certain  ORUs  have  more  demands  than  actual  failures.  Environmental 
problems,  false  removals,  and  scheduled  maintenance  are  examples  of  additional 
demands  that  require  spares.  Sometimes  those  demands  are  defined  by  a  demand 
multiplier  called  a  K-factor  (e.g.,  K  =  1.2  denotes  that  the  ORU  experiences 
20  percent  more  demands  than  failures).  For  such  ORUs,  the  duty  cycle  field  can 
serve  an  added  purpose  and  contain  the  product  of  the  K-factor  multiplied  by  the  duty 
cycle  fraction. 
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INPUT  FILE  FORMAT 


The  M-SPARE  model  directly  reads  the  MSPAREIN.RPT  file  and,  thus, 
requires  the  data  fields  discussed  to  be  in  a  relatively  loose  data  format.  The  order  of 
the  ORUs  is  not  important.  Only  the  relative  positions  of  the  data  fields  are 
significant.  Adherence  to  the  following  format  rules  is  necessary  when  creating  an 
ORU  input  file; 

•  The  ORU  data  starts  on  the  line  immediately  after  the  “>”  character.  The 
“  >  ”  character  is  in  the  first  column. 

•  The  “>”  character  also  marks  the  end  of  the  file  and  is  on  the  line 
immediately  after  the  data  for  the  last  ORU.  The  “>”  character  is  in  the 
first  column  of  that  last  line. 

•  Only  the  first  five  character  fields  are  required  in  particular  columns  of  the 
file.  The  model  assumes  each  of  those  fields  meet  the  exact  widths  specified 
in  our  definitions  and  have  no  extra  characters  between  them.  Make  sure 
the  first  five  column  widths  are  32,  18,  6,  2,  and  7,  and  start  in  Columns  1, 
33, 51,  57,  and  59,  respectively. 

•  None  of  the  other  numeric  fields  have  to  be  in  specific  columns,  but  the  fields 
must  be  separated  by  one  or  more  blanks.  Real  values  can  have  as  many 
decimal  places  as  desired. 

•  Data  for  all  fields  must  be  included.  If  you  do  not  have  data  for  any 
resource  —  QPA,  duty  cycle,  or  VMR  —  place  a  “1”  in  those  fields  and  place  a 
“0”  in  the  MIN.  SPR  field. 

Table  5-1  summarizes  each  field  type  and  file  format.  Also,  the  model  closely 
links  many  of  the  data  fields  to  the  OPTIONS.RPT  file  discussed  in  Chapter  6. 

INPUT  FILE  SUMMARY 

In  conclusion,  you  have  two  options  for  obtaining  an  input  file.  You  may  use  the 
sample  data  base  file  we  supplied  and  use  an  editor  to  modify  the  ORU  data  to  more 
closely  reflect  your  specific  work  package  information,  or  you  may  create  your  own 
input  file  with  another  software  package,  following  the  format  rules  presented 
earlier.  However,  you  must  make  sure  the  package  output  file  is  in  an  ASCII  format, 
sometimes  referred  to  as  a  report,  text,  or  print  file. 
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TABLE  5-1 


SUMMARY  OF  MSPAREIN.RPT  DATA  BASE  FIELDS 


Header 

Field  type 

Column 

first 

Location 

last 

Comment 

NAME 

32-char. 

1 

32 

PART  NUMBER 

IB-char. 

33 

50 

CAGE# 

6-char. 

51 

56 

CT 

2-char. 

57 

SB 

Criticality  code 

DIST  SYSTEM 

7-char. 

59 

65 

Distributed  system 

PRICE  ($K) 

Real  >  0 

space 

delimited 

WEIGHT  (LBS) 

Real  >  0 

space 

delimited 

VOLUME  (INCH  *3) 

Real  >  0 

space 

delimited 

MIN. SPR 

Integer  >  0 

space 

delimited 

Minimum  spare 

P/U  1/0 

0.1.2 

space 

delimited 

Pressurized/unpressurized 

PLTSS 

Integer  >  0 

space 

delimited 

Dollar  spread  vector 

DAYS1 

Real  >  0 

space 

delimited 

KSC  repair  time 

DAYS  2 

Real  2:  0 

space 

delimited 

OEM/prime  repair  time 

Mths3 

Real  >  0 

space 

delimited 

PLT 

FRACTION  1 

Real  s:  0 

space 

delimited 

KSC  repair  fraction 

FRACTION  2 

Real  >  0 

space 

delimited 

OEM  repair  fraction 

FRACTION  3 

Real  >  0 

space 

delimited 

Condemnation  fraction 

Log  Cyc 

Real  >  0 

space 

delimited 

Logistics  cycle 

DUTY  CYCLE 

Real  >  0 

space 

delimited 

VMR 

Real  >  0 

space 

delimited 

VMR 

LIFE  (YR) 

Real  >  0 

space 

delimited 

Mean  time  before  ORU  wear- 
out 

MTBF  (HR)  PER  UNIT 

Real  >  0 

space 

delimited 

MTBF 

QPA1 

Integer  ^  0 

space 

delimited 

QPA2 

Integer  £  0 

space 

delimited 

QPA3 

Integer  >  0 

space 

delimited 

QPA4 

Integer  ^  0 

space 

delimited 

QPA5 

Integer  >  0 

space 

delimited 

QPA6 

Integer  >  0 

space 

delimited 

QPA7 

Integer  >  0 

space 

delimited 
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CHAPTER  6 


MODEL  OPTIONS 


The  model  has  several  options  that  are  triggered  from  the  OPTIONS.RPT  file 
(see  Exhibit  6>1).  This  file  is  accessible  through  the  ''Options’*  choice  on  the  interface 
menu.  The  OPTIONS.RPT  file  is  provided  to  set  key  parameters  that  usually  do  not 
vary  from  one  model  run  to  the  next.  That  simplifies  the  user-query  inputs  required 
for  model  operation  (see  Chapter  7).  In  most  cases,  the  user  uses  the  default  values 
specified  below  for  each  option.  However,  the  OPTIONS.RPT  file  allows  you  the 
flexibility  to  test  some  special  cases  by  changing  the  default  values. 

The  user  can  change  any  of  the  option  values  in  the  file  by  selecting  the 
interface  menu  choice  "Options.**  The  interface  then  invokes  the  editor  and  loads  the 
OPTIONS.RPT  file.  We  then  suggest  you  press  the  "Insert**  key  to  turn  off  the  insert 
mode  and  type  over  any  options  you  want  to  change.  The  replaced  values  do  not  have 
to  be  in  exactly  the  same  columns  as  the  originals  but  merely  in  the  general  vicinity. 
Be  careful  not  to  accidentally  add  any  lines  because  the  model  will  not  read  the 
options  correctly.  When  you  are  done,  press  "ALT-X**  to  save  the  OPTIONS.RPT  file 
and  return  to  the  interface  menu.  The  definition  and  range  of  global  values  are 
discussed  for  each  of  the  options  in  the  following  sections. 

LOGISTICS  CYCLE  DELTA 

The  M-SPARE  model  allows  the  user  to  change  the  planned  logistics  cycle 
without  editing  the  MSPAREIN.RPT  file.  The  logistics  cycle  delta  allows  a  positive 
or  negative  increment  change  in  the  number  of  days  the  model  applies  to  each  ORU 
logistics  cycle.  Thus,  to  analyze  the  impact  of  slipping  cycles  45  days,  set  the  delta 
to  "45**  and  the  model  automatically  adds  45  days  to  each  ORU’s  cycle.  The  logistics 
cycle  delta  is  included  in  Equations  4-6  through  4-9.  The  option  default  value 
equals  "0**. 

STARTING  SPARES 

The  starting  spare  option  allows  the  user  to  set  the  starting  asset  position  by 
year.  If  the  value  equals  "0**,  the  model  run  year  does  not  consider  previous  year 
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MODEL  OPTIONS  FILE 
(OPTIONS. RPT) 


GLOBAL 


VALUE  DESCRIPTION 


0  -  LOGISTICS  CYCLE  DELTA  in  days:  added  to  all  ORU  logistics  cycles 

1  •  STARTING  SPARES;  run  with  or  without  previous  year's  assets 

O-starting  asset  levels  set  to  0  each  year 

1- starting  1eve1>previous  year  assets  -  replaced  condeanations . 

2- starting  1eve1-MIN  SPR  for  1st  yr  damand>0,  else  previous  yr. 

10  -  NUMBER  OF  PASSES:  the  number  of  resource  tradeoffs  performed. 

99.0  -  MAXIMUM  AVAILABILITY  (X)  for  the  resource-vs-avai labi 1 i ty  curve 

1  -  PLOT: 

0  -  produce  no  plots 

1  -  plot  the  resource-vs-availability  curve  and  the 
multiple-pass  curve 

11  -  TRACE  INFO; 11-all,  10-Big  Budget. RPT,  1-Big  OUT. RPT,  0-small  both 

8  -  NUMBER  OF  MODEL  YEARS  in  SSF  life. 

1998  -  FIRST  MODEL  FY  spares  required  for  building  SSF. 

1994  -  FIRST  BUDGET  FY  that  funding  dollars  are  possible 

0  -  FUNDING  SPLIT;0-single  funding  profile 

1-split  out  development  and  operational  funds 
1991  -  BASELINE  FISCAL  YEAR  (fiscal  year  of  ORU  price) 

0  -  PRICE  INFLATOR  PERCENTAGE:  if  OX,  POP  constant  S,  else  current  $ 

0  -  LOTUS:  1-output  tables  formatted  for  import  to  LOTUS,  0-do  not 

0  -  QPA  INPUT  FORMAT 

0  -  QPA  is  cumulative  by  FY  with  First  Fiscal  year 
corresponding  to  the  OPA(l)  column  in  MSPAREIN.RPT) 

1  -  QPA  columns  represent  elements(see  Launch  Schedule  below) 

-1  -  DECREMENT  DAYS:  Moves  end  FY  requirements  impact  earlier. 

If  -1  then  decrement  «  ORU  logistics  cycle 
5  -  WEAR  WAKE:  Wake-MHodel  Year>11fe  limit  for  wear  item.defaulfS 

C  -  DRIVE  LOCATION  for  temporary  files.  Use  RAM  drive  if  possible 
and  if  have  450  bytes  of  memory  per  ORU  available. 

1  -  NUMBER  OF  CRITICALITY  COOES  (e.g..1f  C1,C2.C3  enter  3) 

28  -  REPAIR  PERCENTAGE:  the  ratio  of  repair  to  procurement  cost 

90  -  LABOR  PERCENTAGE:  the  percentage  of  labor  to  the  total  repair  cost 

CUMULATIVE  POP  MARKS  by  crit  code;  constant  $K  If  1nf1ator»0X  else  current  $K 
CRIT  FY90  FY91  FY92  FY93  FY94  FV95  FY96  FY97  FY98  FY99 

1st  0  0  0  0  0  0  5000  32000  88000  156000 

2nd  0  0  0  0  0  0  0  22222  44444  666866 

SPREAD  VECTORS;  The  Fraction  of  unit  cost  spread  over  the  PLT 
Vector  I  -  Years  from  Requirement  (i.e..  Delivery) — [ 

0  [-delivery-! -  Procurement  Leadtime  - [ 

0  -1  -2  -3  -4  -5 

>start  - 

1  0  1  0  0  0  0 

2  0  0.4  0.6  0  00 

3  0  0.2  0.5  0.3  0  0 


>end  of  spread  vectors 

LAUNCH  SCHEDULE  TABLE  (Row  1  corresponds  to  QPA  col  1  in  the 

Flight  #  !  Calendar!  Launch  MSPAREIN.RPT,  etc.  With  this  format 

ROW  /Element  [  Month  [  Year  M-SPARE  produces  cumulative  QPA  by 

> — start  of  schedule -  fiscal  year. 

1  LabA  12  1996 

2  LabB  3  2000 

> — end  of  launch  schedule - 


EXHIBIT  6-1.  MODEL  OPnONS.IU>T  FILE 
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solutions  and  assumes  that  no  spares  assets  exist.  If  the  value  equals  "1”,  then  each 
successive  year  of  the  model  run  uses  the  previous  year’s  assets  (minus  replaced 
condemnations)  as  a  starting  position  and  then  decides  what  spare  to  select  next.  If 
the  option  value  equals  ”2,”  the  model  sets  all  ORU  starting  spares  levels  at  the 
specific  ORU  MIN.  SPR  value  (from  the  input  file  MSPAREIN.RPT)  for  the  first 
model  year  where  ORU  demand  is  greater  than  0.  All  years  after  that  use  the 
previous  year’s  assets.  For  budget  estimates,  the  model  builds  on  the  previous  year’s 
solution  (option  equals  1  or  2).  However,  users  might  want  to  determine  the  spares 
requirements  based  upon  0  starting  assets  each  year  (option  equals  ”0”).  The  default 
option  value  equals  "1”. 

NUMBER  OF  PASSES 

The  M-SPARE  model  is  capable  of  running  a  number  of  passes  for  a  particular 
year  to  help  automate  the  resource  tradeoff  capability.  Exhibit  3-1  displays  the 
iterative  price- versus-weight  solutions  produced  by  the  model.  In  that  example,  the 
maximum  number  of  passes  is  set  to  "lO”.  As  that  value  increases,  the  model 
increases  its  range  and  refines  the  resource  tradeoffs.  In  the  Multiple-Pass  Mode 
section  of  Chapter  7,  we  further  describe  how  that  value  is  used.  The  default  option 
value  equals  ’^10”. 

MAXIMUM  AVAILABILITY 

This  option  allows  the  user  to  set  the  maximum  availability  of  the  resource- 
versus-availability  curve  (expressed  in  percentages).  Depending  on  the  desired  range 
of  solutions,  you  can  set  the  maximum  to  ”99”  percent  or  ”99.99”  percent.  The  default 
option  value  equals  ”99”. 

PLOT 


The  plot  value  allows  the  user  to  switch  the  model’s  plotting  function  off  (value 
equals  ”0”)  or  on  (value  equals  ”1”).  If  the  plot  value  is  on,  the  model  plots  the 
resource-versus-availability  curve  and  if  applicable,  the  multiple-pass  curve.  The 
default  option  value  equals  ”1”. 

Hard  copies  of  any  plot  can  only  be  made  when  the  plot  is  on  your  monitor 
screen.  If  you  have  an  Hewlett-Packard  (HP)  laser  printer,  press  the  ”Space”  bar  or 
type  a  label  and  then  press  ”Enter”  to  make  a  hard  copy.  If  you  have  an  Epson 
printer,  press  the  ”Print  Screen”  key  to  make  a  hard  copy.  [Note:  If  nothing  prints  on 
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your  Epson,  type  the  command  "GRAPHICS”  before  you  start  the  model  or  add  the 
graphics  command  to  your  AUTOEXEC.BAT  file.]  You  can  type  a  label,  such  as  the 
date  or  number,  on  the  hard  copy  to  distinguish  it  from  other  similar  plots.  To  do 
that,  simply  type  the  label  before  printing.  If  you  only  press  "Enter”,  you  can 
continue  without  printing  the  plot. 

TRACE  INFORMATION 

The  M-SPARE  trace  option  gives  the  user  control  of  the  tables  the  model 
generates  in  the  OUT.RPT  and  BUDGET.RPT  files.  When  first  learning  about  the 
model,  the  user  can  generate  all  M-SPARE  table  outputs  for  an  abbreviated  model 
run  (enter  "11”).  For  production  runs,  the  user  can  reduce  the  size  of  the  model 
output  by  some  50  pages  but  still  produce  the  key  solution  tables  (enter  "0”).  The 
specific  option  values  that  follow  specify  the  tables  the  model  generates  between 
those  two  extremes: 

•  11  —  The  model  produces  all  the  OUT.RPT  and  BUDGET.RPT  tables  as 
described  in  Chapter  8  of  the  M-SPARE  documentation. 

•  10  -  The  model  does  not  produce  the  tables  that  display  QPA,  the  resource- 
versus-availability  curve,  and  the  ORU  input  data  in  the  OUT.RPT  file.  The 
model  produces  all  other  reports  from  Option  11. 

•  1  —  The  model  does  not  produce  the  tables  that  display  the  gross  spares 
requirements  by  ORU,  the  spares  budget  estimates  by  ORU,  and  the  next- 
guess  calculation  in  the  BUDGET.RPT  file.  The  model  produces  all  other 
reports  from  Option  11. 

•  0  —  The  model  does  not  produce  the  tables  in  the  BUDGET.RPT  and 
OUT.RPT  as  described  in  Options  10  and  1.  The  model  produces  all  other 
reports  from  Option  11. 

NUMBER  OF  MODEL  YEARS 

The  number  of  model  years  option  determines  the  number  of  years  to  be  run  on 
the  model  (i.e.,  the  number  of  annual  spares  requirements  forecasts).  That  time 
period  begins  when  the  station  starts  the  assembly  stage  and  ends  near  the  end  of  the 
budget  forecast  (see  Figure  6-1).  The  station  starts  assembly  at  the  first  element 
launch,  which  is  based  upon  your  ORU  data  base  (you  may  specify  that  value  in  the 
next  option).  The  end  of  the  period  is  the  last  year  that  spares  requirements  impact 
the  budget.  The  last  year  of  the  model  equals  your  last  budget  year  plus  the  number 
of  years  in  your  maximum  spread  vector  (as  described  in  Chapter  5).  Thus,  the 
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number  of  model  years  in  Figure  6-1  equals  "9”  (FY96  through  FY04).  The  model 
includes  FY04  because  spares  requirements  still  increase  budget  outlays  in  your  last 
budget  year,  FY02  (assuming  a  maximum  spread  vector  of  2  years). 


I -  - 1  I - 1  I - 1  I - 1 


PLT:  I _ I _ I 

Budget:  I  t  I  ^  I  ^  I  ^  I  ^ 

I  I  I  1  1  i  I  1  I _ I _ I _ \ _ I _ l_l 

FY:  94  95  96  97  98  99  00  01  02  03  04  05  06  07 

Fiscal  Year 

FIG.  6-1.  KEY  INPUT  VARIABLES  IN  OPTIONS.RPT  FILE 


FIRST  MODEL  FY 

The  first  model  fiscal  year  determines  what  year  the  model  run  starts.  You 
must  enter  the  fiscal  year  that  your  first  system  is  launched.  Specifically,  that  date 
represents  the  first  fiscal  year  that  any  ORU  in  your  data  base  (MSPAREIN.RPT) 
may  experience  a  failure.  In  Figure  6-1,  it  corresponds  to  ”1996”.  The  QPA  option 
that  follows  contains  additional  information.  The  default  value  is  dependent  upon 
your  MSPAREIN.RPT  file  format. 

FIRST  BUDGET  FY 

The  first  budget  fiscal  year  specifies  the  etirliest  year  that  outlays  can  start  for 
any  spares  procurement.  For  instance,  in  Figure  6-1,  we  assume  ”1994”  is  the  first 
budget  year.  You  may  want  to  increase  or  decrease  that  year.  The  main  impact  of 
this  option  is  that  the  model  will  not  allow  funding  requirements  to  precede  that  first 
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year.  For  instance,  if  the  model  estimates  an  ORU  spare  requirement  in  FY96  and 
the  ORU  spread  vector  is  over  3  years,  any  funds  the  model  would  have  spread  to 
FY93  are  instead  added  to  FY94  (the  first  budget  year).  To  determine  what  funds 
need  to  be  allocated  before  FY94,  set  the  first  year  to  an  earlier  year.  [Note:  You 
cannot  set  the  first  fiscal  year  earlier  than  "1990.”]  Our  current  default  value 
is  "1994”. 

FUNDING  SPLIT 

The  M-SPARE  model  estimates  spares  and  funding  requirements  by  fiscal  year. 
Certain  users  may  require  those  estimates  to  be  broken  down  further  into  two 
different  budget  category  estimates:  development  and  operational  funding  (see 
Chapter  9  for  more  discussion).  If  the  user  needs  that  breakdown,  enter  "1”.  In 
general,  enter  "0”  for  the  default  option. 

BASELINE  FISCAL  YEAR 

The  user  enters  the  dollar  year  of  the  ORU’s  unit  prices  as  the  baseline  fiscal 
year  value.  M-SPARE  assumes  all  ORU  prices  are  for  the  same  year  and  makes  all 
calculations  for  future  years  in  constant  dollars  for  that  baseline  year.  The  model 
uses  the  baseline  fiscal  year  to  convert  back  and  forth  between  constant-year  dollars 
and  current-year  dollars  as  described  in  the  next  option. 

PRICE  INFLATOR  PERCENTAGE 

The  price  inflator  percentage  in  the  OPTIONS.RPT  file  is  the  inflation  rate  the 
user  assumes  over  the  model  time  frame.  The  model  uses  it  to  convert  the  cumulative 
POP  marks  inputs  (a  later  option)  from  current-year  dollars  to  constant-baseline- 
year  dollars.  Then,  M-SPARE  uses  constant  dollars  for  all  its  calculations  and  model 
output.  The  one  exception  is  that  the  BUDGET.RPT  displays  the  last  table  (a  budget 
summary  table)  in  both  constant-year  dollars  and  current-year  dollars.  If  a  constant 
inflator  is  inappropriate  for  you.  Just  enter  "0”  for  the  inflator  and  the  model  assumes 
that  the  POP  marks  are  in  constant  dollars  and  produces  no  summary  table  in 
current-year  dollars. 

LOTUS 

This  option  modifies  the  output  tables  so  that  the  user  can  move  them  for 
further  manipulation  to  spreadsheet  software  (e.g.,  LOTUS  1-2-3,  QUATTRO  PRO, 
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or  Excel).  If  you  enter  a  “1”,  the  model  places  quotes  around  character  fields  in  the 
tables  of  the  BUDGET.RPT  file  and  some  of  the  tables  of  the  OUT.RPT  file.  The 
quotes  allow  certain  spreadsheet  software  to  retrieve  tables  and  automatically 
translate  them  into  spreadsheet  format.  For  LOTUS  1-2-3,  you  “import”  the  file  as 
“numbers”.  For  QUATTRO  PRO,  you  “import”  the  file  using  the  ‘Comma  & 
Delimited’  option  on  the  menu  bar.  For  Excel,  you  open  the  file  as  a  text  file,  set  the 
text  options  delimiter  as  “Custom”  with  double  quotes,  set  the  text  origin  to  DOS,  and 
then  parse  the  number  fields.  If  you  enter  a  “0”  for  the  M-SPARE  LOTUS  option,  the 
model  does  not  print  the  quotes  so  the  table  looks  like  a  standard  document  table. 
The  default  value  for  this  option  equals  “0.” 

QPA  INPUT  FORMAT 

Station  growth,  and  the  corresponding  increase  in  item  failure  rate,  is  reflected 
in  M-SPARE  by  the  ORU  QPA  (quantity  per  application  for  each  ORU)  profile  over 
time  (see  top  of  Exhibit  4-1).  We  currently  have  two  formats  for  that  profile.  If  the 
user  specifies  a  “0”,  the  model  assumes  the  QPA  is  cumulative  by  fiscal  year  with  the 
first  fiscal  year  corresponding  to  the  QPA(l)  column  in  MSPAREIN.RPT.  If  the  user 
specifies  a  “1”,  the  model  assumes  QPA  columns  represent  elements  and  the  model 
calculates  cumulative  QPA  by  fiscal  year  based  upon  the  launch  schedule  (mission 
builds)  at  the  bottom  of  the  OPTIONS.RPT  file.  Figure  6-2  displays  the  two  options. 
If  the  QPA  is  specified  by  fiscal  year,  it  is  only  adjusted  at  the  beginning  of  each  fiscal 
year.  If  QPA  is  specified  by  launch,  it  is  adjusted  the  month  of  each  launch.  The 
latter  is  more  accurate  but  requires  the  data  base  to  contain  more  detail  (see  the 
Demand  Factors  section  in  Chapter  5  for  more  information).  The  default  value  is 
dependent  upon  your  MSPAREIN.RPT  file  format. 

DECREMENT  DAYS 

Decrement  days  determines  when  in  the  fiscal  year  the  last  launch  occurs,  i.e., 
the  logistics  cycle  that  determines  your  spares  requirements  (see  Chapter  1).  The 
model  usually  assumes  the  last  launch  is  a  logistics  cycle  from  the  end  of  the  year  (see 
Figure  6-1).  The  default  value  of  “  —  1”  allows  the  model  to  automatically  change  the 
decrement  to  equal  the  ORU’s  logistics  cycle.  If  you  want  to  experiment  and  change 
the  last  launch  to  the  middle  or  end  of  the  year  enter  a  “180”  or  “0”,  respectively. 
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OptionO:  QPAby fisca'yMr 


Cumulative 

QPA 


96  97  98  99  00  01  02  03 

Fiscal  Year 

Option  1:  QPA  by  launch 

Cumulative 
QPA 


96  97  98  99  00  01  02  03 

Fiscal  Year 

—  element  launch 

FIG.  6-2  QPA  FORMAT  OPTIONS 

WEAR  WAKE 

The  wear  wake  helps  determine  which  ORUs  require  the  simulation  pre¬ 
processor  (see  Chapter  10).  For  instance,  if  the  ORU  mean  wear  life  is  19  years,  a 
wear  failure  may  occur  as  early  as  14  years.  The  wear  wake  for  this  case  equals 
‘*5”  (19  ~  14).  Since  the  maximum  number  of  model  years  is  15,  wear-related  failures 
may  occur  within  the  model’s  timeframe  and  M-SPARE  automatically  uses  the 
simulation  preprocessor.  The  user  can  change  the  wear  wake  setting  based  upon  the 
results  of  a  more  detail  simulation  analysis  or  to  force  M-SPARE  to  use  the 
simulation  for  additional  ORUs.  The  default  value  is  ’*5”  for  this  option. 

DRIVE  LOCATION 

The  drive  location  determines  where  M-SPARE  stores  its  temporary  files.  If 
possible,  you  should  create  a  random  access  memory  (RAM)  drive  in  your  PC’s 
memory.  This  is  a  simulated  disk  drive  that  actually  exists  in  the  PCs  RAM  area.  If 
you  have  the  room  (in  expanded  or  standard  memory),  a  RAM  drive  will  improve  the 
speed  of  the  model  run.  If  you  use  a  RAM  drive,  you  enter  the  letter  of  the  RAM  drive 
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for  this  option.  If  you  do  not  have  a  RAM  drive,  you  enter  a  letter  of  the  hard  disk 
drive  (make  sure  the  drive  has  at  least  a  few  megabytes  of  free  storage).  The 
temporary  files  require  about  1  kilobyte  of  memory  per  ORU.  The  default  value  is 
”0”  for  this  option. 

NUMBER  OF  CRITICALITY  COOES 

The  M-SPARE  model  performs  specific  passes  for  each  criticality  code.  If 
MSPAREIN.RPT  file  contains  Criticality  Codes  1,  2,  and  3,  enter  "3”  for  this  value 
and  the  model  estimates  requirements  for  all  codes.  If  you  want  to  run  the  model  for 
only  one  type  of  criticality  code,  enter  You  can  use  up  to  25  different  criticality 
codes  but  you  must  specify  a  POP  mark  fo:  each  (see  the  next  option).  The  default  is 
dependent  on  your  MSPAREIN.RPT  file. 

REPAIR  PERCENTAGE 

The  repair  percentage  is  the  ratio  of  repair  cost  to  procurement  cost.  The  model 
estimates  the  ORU’s  repair  cost  by  multiplying  the  repair  percentage  times  the 
ORU’s  procurement  cost.  The  model  then  multiplies  the  ORU’s  repair  cost  times  the 
annual  niunber  of  repairs  and  sums  the  product  across  all  ORUs  to  generate  the 
annual  repair  budget.  The  default  value  for  this  option  equals  ”28"  (see  Appendix  B). 

LABOR  PERCENTAGE 

The  labor  percentage  splits  the  annual  repair  budget  (discussed  in  the  previous 
option)  into  repair  cost  estimates  for  labor  and  material.  The  model  multiplies  the 
labor  percentage  times  the  total  repair  cost  to  estimate  the  labor  component  and  one 
minus  the  labor  percentage  to  estimate  the  material  component.  The  default  value 
for  this  option  equals  ”90”  (see  Appendix  B). 

CUMULATIVE  POP  MARKS  TABLE 

The  cumulative  budget  marks  are  fiscal  year  budgets  that  constrain  the  model’s 
spares  estimates.  The  marks  are  by  criticality  code,  in  constant  dollars,  and  in  the 
same  dollar  year  as  the  unit  prices  (unless  the  price  inflator  is  greater  than  zero  than 
the  marks  are  in  current  year  dollars).  The  marks  help  estimate  the  ”price  guess”  so 
that  M-SPARE  produces  budget  estimates  comparable  to  the  POP  marks  (see 
Chapter  9).  If  you  decide  to  run  the  model  for  fewer  than  three  criticality  codes  (i.e., 
number  of  criticality  codes  option  is  less  than  3)  then  put  the  budget  marks  in  the 
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order  of  your  next  M-SPARE  run.  For  instance,  to  run  the  model  for  Criticality  Code 
2  and  Criticality  Code  3  only,  enter  “2”  for  number  of  codes  in  the  option  above  and 
put  budget  marks  for  Criticality  Code  2  in  the  first  row  and  Criticality  Code  3  in  the 
second  row  of  the  marks  matrix.  You  must  make  sure  all  colunms  (from  FY90  to 
FYlO)  contain  a  value  even  if  the  earlier  years  equal  “0”  and  the  later  years  are  all 
the  same.  You  can  add  up  to  25  POP  mark  rows.  When  adding  rows,  just  increase  the 
row  number  (first  column)  by  “1”  and  the  number  of  criticality  codes  in  the  previous 
option. 

SPREAD  VECTORS 

The  spread  vector  table  determines  the  fraction  of  unit  cost  that  accrues  from 
the  start  of  the  PLT  until  the  delivery  year.  Each  ORU  in  the  input  data  bases  has  a 
spread  vector  number.  In  Exhibit  6-1,  Vector  2  corresponds  to  a  spread  of  0.0, 0.4,  and 
0.6.  Those  vector  numbers  specify  that  no  costs  accrue  in  the  year  of  delivery, 
40  percent  of  the  ORU’s  unit  price  accrues  in  the  year  right  before  the  ORU  is 
delivered,  and  60  percent  1  year  earlier.  (This  is  the  vector  we  used  in  the  Chapter  1 
example.)  For  an  ORU  with  a  3-year  PLT,  the  user  may  enter  a  vector  similar  to 
Vector  3.  Notice  that  the  vectors  are  reversed:  you  start  by  specifying  the  fraction  for 
the  delivery  year  (e.g.,  FY99)  and  then  move  back  over  the  PLT  1  year  at  a  time  (e.g., 
FY98,  then  FY97  . . . ).  So  far  we  assumed  that  dollar  outlays  for  particular  spares 
requirements  occur  in  the  previous  fiscal  years  during  the  PLT  (e.g.,  a  spare  in  FY99 
requires  dollar  outlays  in  FY98  and  FY97,  assuming  a  2-year  PLT).  If  you  want  the 
funds  to  accrue  in  the  same  year  as  the  requirement  (e.g.,  a  spare  in  FY99  requires 
dollar  outlays  in  FY99  and  FY98),  you  place  a  value  in  the  first  spread  vector  column 
(labeled  delivery)  and  the  next  column  (labeled  “—1”  year  from  delivery). 
Furthermore,  if  the  full  price  of  the  spare  is  paid  on  delivery,  then  set  the  spread 
vectors  to  “1”  in  the  delivery  year  and  “0”  thereafter.  You  can  add  vectors  by  adding 
similarly  formatted  lines  between  the  data  marker  (“>”).  When  adding  vectors,  you 
must  increase  the  spread  vector  number  (first  column)  by  1 . 

LAUNCH  SCHEDULE  TABLE 

If  the  QPA  format  option  equals  “1”,  then  M-SPARE  requires  a  launch  schedule 
(see  bottom  of  Exhibit  6-1).  The  schedule  defines  the  calendar  month  and  year  of  each 
SSF  element  launch  (mission  builds).  M-SPARE  automatically  converts  launch  year 
into  fiscal  year,  since  fiscal  years  are  the  model’s  time  units.  When  an  entered  year 
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falls  after  the  last  model  year  (e.g.,  “3000”),  the  element  is  not  used  in  the  model  run. 
The  first  row  in  the  table  (LabA)  corresponds  to  the  first  QPA  column  in 
MSPAREIN.RPT.  The  model  calculates  cumulative  QPAs  by  month  by  summing 
QPA  quantities  for  all  elements  previously  launched.  In  the  Exhibit  6-1  schedule, 
QPAs  overtime  is  based  upon  launch  times  for  the  Lab  A,  Node  1,  Cupola  1,  and 
Airlock  launches.  The  cumulative  QPA  profile  appears  at  the  bottom  of  Figure  6-2. 
You  can  add  or  delete  element  launches  by  adding  or  deleting  lines  of  the  file  between 
the  data  markers  (“>”).  Just  make  sure  the  added  launch  dates  have  the  same 
format  as  what  exists  in  your  original  OPTIONS.RPT  file  and  that  the  element  name 
does  not  extend  past  Column  15. 
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CHAPTER  7 


MODEL  OPERATION  AND  ANALYSIS 


This  chapter  discusses  how  to  run  M-SPARE  and  the  various  types  of  analyses 
it  can  perform.  By  this  point,  we  assume  you  opened  the  M-SPARE  interface  (see 
Chapter  2)  and  developed  the  three  inputs  required  to  run  the  model.  Those  inputs 
are  the  MSPAREIN.RPT  file  that  contains  the  ORU  data  base,  the  OPTIONS.RPT 
file  that  contains  M-SPARE  parameters,  and  the  wear  preprocessor  that  develops 
aggregate  demand  parameters.  Those  inputs  change  relatively  infrequently.  Most  of 
the  parameters  can  be  adjusted  via  the  M-SPARE  query  selection  we  will  now 
discuss. 

The  basic  steps  to  execute  M-SPARE  on  your  PC  are  the  following: 

•  Enter  “CD\SPARE”  to  move  to  the  SPARE  directory  if  not  already  there. 

•  Enter  “START”  to  enter  the  M-SPARE  interface. 

•  Enter  “R”  to  run  M-SPARE. 

The  basic  model  operation  is  to  run  one  criticality  code  at  a  time.  Once  a 
criticality  code  is  selected  by  the  user,  the  model  then  steps  through  each  year  of  the 
station’s  life  (see  Figure  1-1).  For  each  year,  it  asks  you  to  enter  some  basic 
parameters  and  then  it  determines  what  spares  this  criticality  requires.  With  each 
new  year,  the  number  and  quantity  of  ORUs  in  the  station  change  as  the  station 
configuration  changes.  Annual  spares  requirements  reflect  these  changes.  The 
number  of  yearly  iterations  depend  upon  the  number  of  years  in  the  budget  projection 
and  is  set  by  the  number  of  model  years  you  specified  in  the  OPTIONS.RPT  file  (see 
Chapter  6).  When  the  model  finishes  calculating  the  yearly  iterations,  it  repeats  the 
process  for  the  next  criticality  code.  When  it  finishes  with  all  the  criticality  codes,  it 
then  computes  the  budget  for  all  ORUs  from  all  criticality  codes. 

Exhibit  7-1  is  the  first  query  that  appesurs  on  your  monitor  when  you  run 
M-SPARE.  It  asks  you  to  select  a  criticality  code.  M-SPARE  develops  spares 
requirements  one  criticality  code  at  a  time.  You  now  enter  a  criticality  code  of  one  or 
two  characters.  If  you  enter  a  single  character  such  as  a  “1”,  the  model  selects  all 
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ORUs  with  a  1,  as  the  first  character  in  its  criticality  code.  That  means  ORUs  with 
1  and  IR  become  the  selected  ORUs  for  the  spares  optimization.  If  you  wish  to  run  a 
subset  of  Criticality  Code  1  separately,  you  enter  two  characters  such  as  “1  ”  or  “IR” 
for  nonredundant  and  redundant  ORUs.  The  model  is  sensitive  to  upper  and  lower 
case  letters  so  that  a  IR  and  a  Ir  are  not  the  same. 


Enter  Cnticality  Code  ( 1,2,3, 1R,2R.  .. ) 

To  combine  Cnt  1  &  IR  enter  "1" 

To  separate  Cnt  1  &  IR  enter  ”1R"  &  "l_"  (add  space) 
Careful,  the  model  is  sensitive  to  super  &  lower  case 
so  a  Ir  and  a  IR  are  different  codes 
1 
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EXHIBIT  7-1.  CRITICALITY  CODE  QUERY 


The  screen  shown  in  Exhibit  7-2  appears  next.  This  is  the  monitor  screen  you 
will  return  to  with  each  new  model  year  or  if  you  want  to  start  over.  For  now,  simply 
press  “Enter”  for  rim.  A  dialog  box  similar  to  Exhibit  7-3  will  appear. 

Exhibit  7-3  displays  the  five  menu  choices  (top  of  box).  The  text  in  the  bottom 
part  of  the  box  presents  the  status  information  on  the  model  year,  fiscal  year,  and 
criticality  code  for  the  current  model  iteration.  The  menu  choices  succinctly 
summarize  the  capabilities  or  modes  of  M-SPARE.  Each  mode  has  a  specific  purpose 
and  each  is  described  in  a  separate  section  in  this  chapter.  The  modes  are  as  follows: 

•  Multiple-pass  mode  performs  tradeoffs  between  ground  and  on-orbit  storage 
and  between  two  resources.  The  model  performs  multiple  passes  and 
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EXHIBIT  7-2.  INITIAL  YEAR  MENU 


Multiple  Pass:  (orbit  &  ground) 
Single  Pass:  (orbit  &  ground) 
Ground  Stock  Only 
Minimum  Spares  Evaluation 
Global  ORU  POS  Mode 


Model  Year 
Fiscal  Year 
Criticality  Code 


EXHIBIT  7-3.  MODEL  RUN  OPTIONS  MENU 
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automatically  varies  the  relative  importance  (the  coefficients)  between 
resources  for  each  pass. 

•  Single-pass  mode  allows  you  to  specify  the  resource  coefficients  in  order  to 
examine  a  specific  pass  solution.  You  may  also  specify  your  own  coefficients 
and  calculate  tradeoffs  between  ground  and  on-orbit  storage. 

•  Ground-stock-only  mode  changes  the  model  orientation  to  handle  those 
ORUs  that  can  only  be  stored  on  the  ground  such  as  noncritical  ORUs. 

•  Minimum  spares  evaluation  mode  (not  operational). 

•  Global  ORU  POS  mode  estimates  the  ground  availability  of  setting  each 
ORU  to  a  user-specified  POS  target. 

In  our  discussion  of  each  of  those  modes  and  their  respective  inputs,  we  start  with  the 
single-pass  mode  and  then  describe  the  other  modes  in  the  order  listed  above.  We 
deal  with  the  single-pass  mode  of  operation  first  because  that  is  the  building  block  for 
generating  more  complex  analyses  such  as  the  multiple-pass  mode. 

To  select  the  single-pass  mode,  you  press  the  “  I  ”  key  until  the  mode  is 
highlighted  and  then  press  “Enter”  (you  can  also  press  the  bold  or  red  letter  of  the 
mode  “S”  or  select  the  mode  with  your  mouse).  Your  monitor  displays  a  screen 
similar  to  Exhibit  7-4.  Once  you  enter  a  mode  dialog,  pressing  the  ‘Tab”  key  will 
allow  you  to  step  through  the  queries.  Press  “Enter”  (or  the  “OK”  button)  when  you 
have  answered  all  queries.  If  you  wish  to  go  back  to  a  query,  keep  pressing  the  “Tab” 
key  to  cycle  through  the  list  again  or  use  a  mouse  to  make  a  selection.  In  addition, 
the  model  remembers  your  previous  year’s  dialog  selection  and  keeps  them  as  the 
starting  conditions  for  the  current  year.  An  important  point  is  that  even  if  the 
dialogue  is  properly  set  from  the  previous  year,  you  must  press  the  “Tab  ”  key  before  you 
press  “Enter”  to  begin  execution.  If  you  select  the  wrong  mode,  press  the  “Escape”  key 
or  the  cancel  button  to  start  over  again  and  the  Exhibit  7-2  screen  will  appear  on  your 
monitor.  To  exit  or  abort  an  M-SPARE  run  entirely,  select  “Exit”  from  the  menu  in 
Exhibit  7-1.  Once  the  model  starts  calculating,  you  can  exit  by  pressing  “Ctrl- 
Break”. 

SINGLE-PASS  MODE 

The  M-SPARE  model  requires  three  types  of  station  (system)  inputs:  targets, 
resource  coefficients,  and  PLT  months.  Targets  are  station  goals  (e.g.,  availability) 
that  det?nnjpe  the  spares  solution  point  on  the  resource-versus-availability  curve. 
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Resource  coefficients  are  factors  we  have  developed  to  effect  the  model  optimization 
process.  Coefficients  determine  the  relative  importance  of  each  of  the  resources.  The 
more  important  a  resource,  the  more  the  model  conserves  that  resource  expenditure. 
The  user  can  further  modify  the  spares  selection  process  by  choosing  ORUs  with  PLTs 
(MSPARIN.RPT  field  labeled  “mths  3”)  less  than  some  maximum  value.  Since  that 
input  helps  the  user  match  a  particular  budget  (POP  marks),  we  describe  that  last 
query  in  the  Constrained  Budget  Product  section  of  Chapter  9.  For  now,  you  can 
ignore  this  query  merely  by  keeping  the  default  value  of  “0”. 

M-SPARE  handles  four  categories  of  targets,  including  (1)  availability  —  the 
minimum  acceptable  station  performance  the  user  wants,  (2)  cumulative  weight  (past 
and  present  model  years)  —  the  maximum  number  of  pounds  allotted  for  spares  on 
shuttle  flights,  (3)  cumulative  price  —  the  total  investment  in  spares,  and 
(4)  cumulative  volume  —  the  maximum  on-orbit  storage  volume  in  cubic  inches.  You 
must  enter  one  to  four  of  the  targets.  If  you  enter  more  than  one  target,  the  model 
stops  when  the  first  value  of  any  of  the  targets  is  met.  That  determines  the  spares 
mix  solution.  If  you  do  not  have  to  or  do  not  want  to  consider  a  target,  enter  “0”.  A 
"0”  automatically  sets  the  target  to  a  maximum  value  for  you. 

The  model  also  handles  three  resource  coefficients:  price,  weight,  and  volume. 
Equation  7-1  presents  the  linear  combination  of  coefficients  and  resources  used  to 
estimate  the  on-orbit  unit  resource  for  the  model  (a  slight  modification  to 
Equation  4-4). 


unit  resource^  =  +  (cw)LBSi  , 


where 

i  =  ORU  index 

cp  =  price  coefficient 

cw  =  weight  coefficient 

cv  —  volume  coefficient 

$K  =  ORU  unit  price  in  $l,000s 

LBS  =  ORU  unit  weight  in  pounds 

IN ‘3  =  ORU  unit  volume  in  cubic  inches. 


[Eq.  7-1] 
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Exhibit  7-4  displays  the  coefTicieat  and  target  queries  you  specify  for  this 
operation  mode.  As  you  increase  the  relative  size  of  one  coefficient  to  another,  the 
model  will  tend  to  “conserve”  that  total  resource  expenditure.  For  instance,  you  first 
might  wish  to  treat  all  resources  equally,  then  enter  a  “1”  for  each  coefficient  and 
specify  your  targets.  After  the  model  runs,  you  notice  that  weight  is  the  only  resource 
at  (just  below)  its  target.  Run  the  model  again  with  all  the  same  input,  but  this  time 
enter  an  “8”  for  the  weight  coefficient.  Now  weight  has  relatively  greater  importance 
than  the  other  two  coefficients.  The  model  will  try  to  conserve  weight,  sacrificing  cost 
and  volume.  The  result  is  the  station  availability  increases  under  the  same  resource 
constraints. 


Run 


Exit 


|f=  (  sas=E&a!=!aaa&  Single-Pass  Mode  Dialog 


Model  Year;  1 

Fiscal  Year;  1998 
Crit  Code;  1 

Enter  Volume  Coefficient  0 

Enter  Price  Coefficient  1 

Enter  Weight  Coefficient  0 

Enter  Cumulative  Volume  Target  in  cubic  inches:  0 

Enter  Cumulative  Price  Target  in  SlOOOs:  0 

Enter  Cumulative  Weight  Target  in  pounds;  0 

Enter  Availability  Target  from  0  to  100  percent:  0 

Enter  maximum  PIT  (months)  for  spare  ORUs:  0 

[Note:  A  "0"  above  means  ignore  (set  to  Max).] 


Tab  Next  Query  Return  OK-Done 
Tab-Return  OK-Oone  Esc  Cancel  Tab  Next  Query 


FI  Menu 


Ctrl -Break  Exit 


EXHIBIT  7-4.  SINGLE-PASS  MODE 


You  might  wonder  why  we  suggested  an  8  as  the  weight  coefficient.  Why  not 
a  5?  Is  it  necessary  to  try  every  possible  combination?  The  answer  to  the  last 
question  is  yes,  to  some  degree.  That  is  why  we  have  developed  a  multiple-pass 
version  of  the  model  that  will  automatically  vary  the  coefficients  for  you.  That  is  the 
topic  of  our  next  section. 
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MULTI j^LE-PASS  MODE 


The  purpose  of  the  multiple-pass  mode  is  to  perform  incremental  tradeoffs 
between  two  resources  and  to  present  the  possible  solutions.  In  Chapter  3,  we 
discussed  how  the  model  varies  the  relative  importance  (the  coefficient)  of  two 
resources  and  generates  the  cost-versus- weight  solutions  of  Exhibit  3-1.  In  this 
section,  we  discuss  the  user  inputs  that  were  used  to  generate  that  exhibit  and  the 
t3rpes  of  analyses  the  model  can  perform. 


Once  you  select  the  multiple-pass  mode  of  operation,  a  screen  similar  to 
Exhibit  7-5  displays  model  queries.  For  this  mode,  the  model  varies  the  relative 
importance  of  two  resource  types  at  a  time,  though  all  three  resources  are  included  in 
the  unit  resource  Equation  7-2.  Select  a  resource  tradeoff  by  pressing  ‘Tab”  and  then 
the  “  i  ”  key  to  highlight  the  desired  tradeoff  (a  dot  appears  in  front  of  the  selection  ). 
For  example,  select  a  price-versus-weight  tradeoff,  then  select  the  next  query,  “enter 
a  coefficient  not  in  the  chosen  tradeoff,”  or  the  volume  coefficient.  Pressing  the  “Tab” 
key  also  lets  you  move  to  enter  target  values.  When  you  are  finished,  press  the 
“Enter”  key  to  start  the  current  model  year  run. 


Run  Exit 


[ 


Multiple-Pass  Mode  Dialog 


Select  desired  Trade  Off  Model  Year; 

(•)  Prlce-vs-Me1ght  Fiscal  Year: 

(  )  PrIce-vs-Volunie  Crit  Code: 

(  )  Welght-vs-Volume 

Enter  Coefficient  not  In  chosen  Tradeoff; 

Enter  Cumulative  Volume  Target  In  cubic  Inches: 

Enter  Cumulative  Price  Target  in  SlOOOs: 

Enter  Cumulative  Weight  Target  in  pounds: 

Enter  Availability  Target  from  0  to  100  percent: 

Enter  maximum  PLT  (months)  for  spare  ORUs: 

[Note:  A  ”)”  above  means  ignore  (set  to  Max).] 


1 

1998 

1 


Tab-Return  OK-Oone 


Esc  Cancel  Tab  Next  Query 


\^1  Menu 


Ctrl -Break  Exit 


EXHIBIT  7-5.  MULTIPLE-PASS  MODE 
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Notice  that  in  Equation  7-2  the  three  resource  coefficients  used  in  Equation  7-1 
cp,  cw,  and  cv  are  now  modified  to  c,  (1  — c),  and  a  constant,  respectively.  If  you 
selected  a  different  resource  tradeoff  in  the  first  query,  then  c  is  the  coefficient  for  the 
first  resource,  (1-c)  is  the  coefficient  for  the  other  tradeoff  resource,  and  you  enter 
the  constant  for  the  third  resource  coefficient. 

unit  resource  i  —  +(l~c)LBSj  +  (constant)  IN ‘3 1  >  [Eq.  7-2] 


where 


i  = 

$K 
LBS 
IN‘3 

constant  = 
c  = 

Pass  = 
MaxPass  — 


ORU  index 

ORU  unit  price  in  $ 1,000s 

ORU  unit  weight  in  pounds 

ORU  unit  volume  in  cubic  inches 

coefficient  that  is  held  constant  over  all  the  passes 

1  —  (Pass/MaxPass) 

pass  number 

maximum  number  of  passes,  set  in  the  OPTIONS.RPT  file. 


For  the  example  in  Chapter  3,  Exhibit  3-1,  the  model  pass  number  ranged  from 
0, 1,  2,  etc.,  up  to  10;  the  price  coefficient,  c,  ranged  from  1,  0.9,  0.8,  etc.,  down  to  0.0; 
and  the  weight  coefficient,  (1  — c),  ranged  from  0,  0.1,  0.2,  etc.,  up  to  1,  respectively. 
(For  our  example,  since  we  entered  a  “0”  for  the  volume  coefficient  constant,  volume 
is  basically  not  considered  in  the  unit  resource  equation.)  For  each  pass,  the  relative 
importance  between  price  and  weight  is  adjusted.  That  relative  importance  is  the 
ratio  of  the  coefficients  [(1  —  c)/c].  At  Pass  1,  weight  is  about  one-tenth  (0.1/0.9  =  0.11) 
as  important  a?  price.  At  Pass  9,  weight  is  9  times  (0.9/0. 1  =9)  ’nore  important  than 
price.  (That  ratio  also  can  be  thought  of  as  a  factor  that  converts  pounds  into  dollars.) 


If  you  increase  the  maximum  pass  number  from  “10”  to  “100”,  Pass  1  now 
makes  weight  one-hundredth  as  important  as  price,  and  Pass  99  makes  weight 
99  times  more  important  than  price.  Thus,  the  maximum  pass  number  is  a  way  to 
increase  the  range  and  refine  resource  tradeoffs.  A  large  maximum  pass  number  is 
useful  to  ensure  the  model  has  tested  every  possible  combination,  especially  if  the 
total  resource  magnitudes  are  significantly  different  (e.g.,  unit  volume  is  100  times 
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larger  than  unit  weight  on  the  average).  The  key  point  is  that  as  the  resource’s 
relative  importance  increases,  the  model  “conserves”  or  reduces  its  total  resource 
expenditure. 

Once  the  model  has  run  all  the  passes,  it  chooses  one  as  a  solution.  It  then 
reruns  that  pass  to  generate  the  spares  mix  and  resource-versus-availability  curve. 
In  general,  the  solution  is  the  pass  with  the  greatest  station  availability  given  the 
same  resource  constraints. 

If  you  enter  only  an  availability  target  or  only  a  price  target,  the  model  solution 
is  then  the  pass  that  is  less  than  1  percent  over  the  minimum  price  and  has  the  least 
weight.  Exhibit  7-6  presents  the  pass  solutions  table  from  the  test  drive  discussed 
earlier.  In  that  case,  the  pass  with  the  minimum  price  is  the  first  pass  because  it  does 
not  consider  weight  and  stores  all  spares  on  orbit.  Even  though  there  is  no  weight 
target,  storing  all  spares  on  orbit  is  not  a  practical  solution.  As  discussed  in  Chapter 
3  (see  Exhibit  3-1),  a  solution  that  considers  weight  and  price  near  the  elbow  of  the 
curve  is  preferable.  Other  choices  are  “penny  wise  and  pound  foolish.”  Thus,  the 
model  solution  is  the  pass  with  the  least  weight  that  is  vdthin  1  percent  of  the 
minimum  price.  In  Exhibit  7-6,  that  pass  is  Pass  5.  Pass  5  now  becomes  the  model 
solution.  (It  is  repeated  as  the  last  pass  in  the  exhibit.) 


PASS 

SOLUTIONS: 

resources 

assxsxsssssj 

.....COEFFICIENTS 

S  S  S  X  ■  s  * 

1 

PASS 

AVAIL 

PRICE:SK 

WEIGHT; lbs 

VOLUME; in "3 

PRICE 

WEIGHT 

VOLUME 

0 

95.0443 

193306 

26545 

2964042 

1.0000 

0.0000 

0.0000 

1 

95.5527 

196225 

16164 

2179708 

0.9000 

0.1000 

0.0000 

2 

95.5168 

196225 

15717 

2165476 

0.8000 

0.2000 

0.0000 

3 

95.1487 

195285 

14069 

1650340 

0.7000 

0.3000 

0.0000 

4 

95.1044 

195285 

13824 

1637332 

0.6000 

0.4000 

0.0000 

5 

95.0214 

195230 

13556 

1613500 

0.5000 

0.5000 

0.0000 

6 

95.0258 

200420 

11004 

1243078 

0.4000 

0.6000 

0.0000 

7 

95.0070 

200815 

10847 

1233238 

0.3000 

0.7000 

0.0000 

8 

95.0158 

202708 

10514 

1219270 

0.2000 

0.8000 

0.0000 

9 

95.2954 

207611 

10260 

1217178 

0.1000 

0.900C 

0.0000 

10 

95.6330 

403515 

9061 

1143198 

0.0000 

1.0000 

0.0000 

11 

95.0214 

1952.30 

13556 

1613500 

0.5000 

0.5000 

0.0000 

V _ J 


EXHIBIT  7-6.  PASS  SOLUTIONS  TABLE 
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A  point  about  doing  analyses  with  the  model  in  this  mode:  if  you  want  a 
complete  range  of  tradeoffs  between  two  resources,  only  set  an  availability  target;  if 
you  want  the  best  solution  for  a  number  of  targets,  enter  the  targets.  However,  if  you 
enter  the  targets,  the  resource  tradeoff  curve  then  becomes  less  informative. 

GROUND-STOCK-ONLY  MODE 

The  ground-stock -only  mode  is  selected  when  the  ORU  data  base  contains  ORUs 
whose  spares  are  only  stored  on  the  ground.  Those  units  are  usually  the  noncritical 
ORUs  (Criticality  Code  3)  for  which  station  availability  is  less  meaningful.  With  no 
on-orbit  spares,  the  station  availability  is  determined  largely  by  the  probability  of  no 
failures  over  the  cycle.  (Calculated  availability  is  typically  low,  reflecting  the 
decision  that  some  shortages  of  spares  of  these  items  can  be  tolerated.)  Because  of 
that,  we  have  modified  the  model  to  use  a  more  meaningful  availability  measure, 
ground  availability.  This  is  a  measure  of  probability  that  all  ORUs  have  sufficient 
ground  spares  to  replace  all  failures  from  the  previous  logistics  cycle.  Using  the 
ground  availability  measure  does  not  affect  the  spares  selection  process  we  discussed. 

Since  no  spares  are  stored  on  orbit,  this  operational  mode  is  only  concerned  with 
one  resource,  price.  Therefore,  the  price  coefficient  is  automatically  set  to  1  (the  rest 
are  set  to  0).  You  must  select  between  a  ground  availability  or  a  price  target. 
Exhibit  7-7  shows  the  queries  available  when  you  choose  this  option.  First  press  the 
“Tab”  key  and  select  the  target  type  with  the  “  I  ”  key.  Once  you  selected  a  target, 
press  “Tab”  again  and  enter  the  target  in  the  box  (a  value  between  0  to  100  if  you 
previously  selected  an  availability  target  or  a  value  in  thousands  of  dollars  if  you 
previously  selected  a  price  target).  Finally,  you  press  return  to  start  the  current 
model  year  run. 

MINIMUM  SPARES  EVALUATION  MODE 

(This  option  is  currently  not  available.) 

GLOBAL  ORU  POS  MODE 

The  global  ORU  probability-of-sufficiency  (POS)  mode  is  available  because  it 
provides  a  common  starting  point  since  many  NASA  work  packages  are  familiar  with 
the  POS  measure.  For  the  POS  mode  of  operation,  the  model  selects  enough  spares  so 
that  each  ORU  POS  is  greater  than  or  equal  to  a  user-specified  POS  goal. 
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Ground-Stock-Only  Mode  Dialog 


Select  Target  Type  I 

(•)  Cumulative  Price  in  1000s  of  dollars 
(  )  Ground  Availability  from  0  to  lOOX  i 

Enter  selected  Target  in  appropriate  units: 

Enter  maximum  PIT  (months)  for  spare  ORUs: 

[Note:  A  "0"  above  means  ignore  (set  to  Max).] 


Exhibit  7-8  shows  the  queries  available  when  you  choose  this  option.  Similar  to 
the  optimal  approach,  the  POS  measure  considers  two  spares  locations:  ground  and 
on-orbit.  The  “Ground  POS”  estimates  spares  requirements  assuming  ground  stock 
only;  the  “Orbit  POS”  estimates  spares  requirements  under  the  limiting  assumption 
that  all  spares  are  stored  on  orbit.  The  POS  methodology  does  not  optimize  spares 
locations,  nor  does  it  consider  resources  other  than  dollars.  Thus,  it  cannot  produce 
an  optimal  mix  of  ground  and  orbit  spares.  The  POS  is  estimated  by  a  Poisson 
distribution  (see  Equation  4-1)  with  a  mean  equal  to  the  mean  number  of 
unserviceable  imits  at  shuttle  launch  (MB)  for  the  ground  POS  option  or  a  r'ean 
equal  to  the  mean  number  of  orbit  failures  for  the  next  logistics  cycle  (MO)  plus  MB 
for  the  orbit  POS  option. 

Once  you  select  this  POS  mode,  you  must  select  either  the  orbit  or  groimd  POS 
type.  First,  press  the  ‘Tab”  key  and  then  select  POS  type  with  the  “  |  ”  key.  Then, 
press  the  “Tab”  key  again  and  enter  the  POS  target  from  “0”  to  “100”  (percent).  This 
alternative  is  not  used  to  generate  a  spares  list  but  rather  to  give  users  a  familiar 
value  to  compare  with  those  of  the  optimization  model  runs. 
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Run 


E*it 


—  I  '  ===  Global  ORU  POS  Mode  Dialog 

Select  Target  Type 
(  )  Orbit  POS:  All  stock  on-orbit 
()  Ground  POS;  Ground  Stock  Only 

Enter  that  POS  Target:  0  to  100%  0 


Tab-Return  OK-Oone  Esc  Cancel 


Mcde’  Year:  1 

f . .  al  Year:  1998 
Cnt  Code:  1 


El  Menu 


ALT-X  Exit 


EXHIBIT  7-8.  GLOBAL  ORU  POS  MODE 
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CHAPTER  8 


MODEL  OUTPUTS 


Running  the  model  produces  two  files.  One  model  output  file  (BUDGET.RPT) 
summarizes  the  budget  results  and  targets  across  all  criticalities  and  fiscal  years. 
The  other  output  file  (OUT.RPT)  presents  the  basic  inputs  and  detail  spares 
requirements  by  criticality  and  model  year.  To  better  understand  this  chapter’s 
discussion,  you  may  want  to  follow  along  by  browsing  the  files  using  the  supplied 
editor  (select  the  “View”  menu  option  and  then  select  the  appropriate  file).  We  will 
first  discuss  BUDGET.RPT  and  then  OUT.RPT. 

THE  BUDGET  OUTPUT  FILES  (BUDGET.RPT) 

The  model  produces  six  types  of  budget  output  tables.  The  first  table  is  the 
annual  budget  by  model  year  and  criticality.  That  table  gives  summary  results  so 
that  the  user  can  target  the  model  to  select  spares  based  upon  the  POP  marks  (as 
described  in  Chapter  9).  The  next  three  tables  produce  gross  spares  requirements, 
net  spares  requirements,  and  spares  budget  estimates  by  ORU  and  fiscal  year.  Those 
tables  reflect  the  methodology  described  in  Table  1-2.  The  next  table  tyx)e  displays 
budget  summary  information  (i.e.,  dollars  summed  across  all  ORUs)  for  spares 
budgets,  wear  ORU  budgets  (a  subset  of  the  spares  budgets),  and  repair  budgets  (a 
supplementary  model  estimate  that  we  discuss  shortly).  All  tables  are  formatted  so 
that  they  can  be  imported  to  spreadsheet  software  for  further  manipulation  (as 
discussed  in  Chapter  6). 

Annual  Budgets  by  Model  Year  and  Criticality 

An  important  function  of  M-SPARE  is  to  determine  what  spares  are  required 
given  the  POP  marks.  Although  both  M-SPARE  inputs  and  POP  marks  are 
presented  in  constant  dollars  and  closely  linked,  the  two  differ  significantly.  The 
total  annual  budgets  by  model  run  year  table  (see  Exhibit  9-1)  helps  the  user 
determine  which  M-SPARE  targets  to  input  so  that  the  resulting  budget  equals  the 
POP  marks.  We  discuss  this  process  in  Chapter  9. 


Gross  Spares  Requirements  by  Fiscal  Year  Table 

The  table  in  Exhibit  8-1  displays  the  gross  spares  requirements  by  ORU  and  by 
fiscal  year.  (The  requirements  do  not  include  replaced  condemnations.)  The  table 
also  presents  information  on  each  ORU  unit  price,  part  number,  CAGE  numbers,  and 
PLT  spread  vector  (to  the  right  of  the  fiscal  year). 


GROSS  SPARES  REQUIREMENTS  BY  FISCAL  YEAR 


> 

ID  NAME(18) 

1994 

199S 

1996 

1997 

1998 

1999 

2000 

1 

"RADIATOR 

0.0 

0.0 

0.0 

0.0 

2.0 

2.0 

2.0 

2 

"PFCS 

0.0 

0.0 

0.0 

0.0 

3.0 

3.0 

4.0 

3 

"BATTERY  ORU 

0.0 

0.0 

0.0 

0.0 

3.0 

5.0 

8.0 

4 

"BCDU 

0.0 

0.0 

0.0 

0.0 

6.0 

8.0 

13.0 

5 

"DC  SWITCH  UNIT 

0.0 

0.0 

0.0 

0.0 

5.0 

7.0 

10.0 

V _ 

EXHIBIT  8-1.  GROSS  SPARES  REQUIREMENTS  BY  FISCAL  YEAR 


Net  Spares  Requirements  with  Replaced  Condemnations  by  Fiscal  Year  Table 

The  table  in  Exhibit  8-2  presents  the  net  spares  by  ORU  and  fiscal  year  and 
includes  replaced  condemnations.  The  model  calculates  the  net  spares  for  a  fiscal 
year  by  finding  the  gross  spares  requirements  of  the  fiscal  year  minus  the  gross 
spares  requirements  of  the  previous  fiscal  year  plus  replaced  condemnations  (see 
Chapter  4  for  more  discussion).  The  table  also  presents  (not  displayed)  total  net 
spares  summed  across  all  fiscal  years  (“Sum  FYs”),  and  whether  or  not  the  ORU  used 
the  preprocessor  (a  “1”  or  a  “0”  in  the  “wear”  column,  respectively). 

Spares  Budget  Estimates  by  Fiscal  Year  Table 

The  table  in  Exhibit  8-3  presents  the  spares  budgets  by  ORU  and  fiscal  year.  It 
is  similar  to  the  bottom  half  of  Table  l-2c  where  spares  buys  are  multiplied  by  unit 
costs  and  then  spread  across  the  PLT. 

Summary  Budget  Estimates:  Total  Table 

The  table  shown  as  Exhibit  8-4  displays  budget  summaries  in  thousands  of 
constant  dollars.  The  first  budget  row  is  the  budget  for  wear  or  preventive 
maintenance  (also  termed  scheduled  maintenance)  ORUs  (i.e.,  those  ORUs  that 
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NET  SPARES  REQUIREMENTS  INCLUDING  REPLACED  CONDEMNATIONS  BY  FISCAL  YEAR 


> 

ID  NAME(18) 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

1 

"RADIATOR 

0.0 

0.0 

0.0 

0.0 

2.0 

0.0 

0.0 

2 

"PfCS 

0.0 

0.0 

0.0 

0.0 

3.0 

0.0 

1.0 

3 

"BATTERY  ORU 

0.0 

0.0 

0.0 

0.0 

3.0 

2.0 

3.0 

4 

"BCOU 

0.0 

0.0 

0.0 

0.0 

6.0 

2.0 

5.0 

5 

"DC  SWITCH  UNIT 

0.0 

0.0 

0.0 

0.0 

5.0 

2.0 

3.0 

V _ J 


EXHIBIT  8-2.  NET  SPARES  REQUIREMENTS 


.  ^ 


•  4 

SPARES  BUDGET  ESTIMATES  BY 

FISCAL 

YEAR  IN  : 

300’S  OF 

CONSTANT 

DOLLARS 

> 

ID  NAME (18) 

1994 

1995 

1996 

1997 

1998 

1999 

1 

"RADIATOR 

0.0 

0.0 

3502.8 

2335.2 

0.0 

1751.4 

2 

"PFCS 

0.0 

3205.8 

5343.0 

3205.8 

1781.0 

712.4 

3 

"BATTERY  ORU 

0.0 

1075.5 

2509.5 

2987.5 

4063.0 

10157.5 

4 

"BCOU 

0.0 

2678.4 

5356.8 

5505.6 

5208.0 

3422.4 

5 

"DC  SWITCH  UNIT 

0.0 

793.5 

1639.9 

1534.1 

1005.1 

476.1 

; 


EXHIBIT  8-3.  SPARES  BUDGET  ESTIMATES  BY  FISCAL  YEAR 


require  the  wear  preprocessor  because  their  failure  rates  are  time  dependent  —  see 
Chapter  10).  The  model  displays  that  subset  because  some  users  require  a  separate 
budget  category  for  those  types  of  ORUs.  The  model  also  produces  an  aggregate 
budget  (both  wear  and  random  ORUs)  titled  the  annual  model  budget  (the  next  row). 
Next,  the  table  displays  the  annual  and  cumulative  POP  marks  so  that  you  can 
compare  the  model’s  estimates  with  a  potential  spending  cap. 

Summary  Budget  Estimates:  Repairs  Plus  Spares  Table 

The  M-SPARE  model  also  produces  annual  repair  budgets  that  are  consistent 
with  its  spares  calculation.  The  repair  budget  starts  where  the  spares  budget  leaves 
off.  That  is,  once  you  procure  the  spare,  you  then  incur  repair  cost  for  keeping  the 
spare  operational.  M-SPARE  begins  the  repair  budget  calculation  at  the  ORU  level 
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SUMMARY  BUDGET  ESTIMATES  (THOUSANDS  OF  CONSTANT  1991  DOLLARS) 


Total  ($K)/FISCAL  YEAR: 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

Annual  Wear  &  PM  Subset 

0 

1076 

2510 

2988 

3346 

7529 

16252 

Annual  Model  Budget 

0 

20505 

60536 

61136 

49277 

39931 

29002 

Annual  PDP  Marks 

0 

0 

5000 

27000 

56000 

68000 

70000 

Cumulative  Model  Budget 

0 

20505 

81041 

142177 

191454 

231386 

260387 

Cumulative  PDP  Marks 

0 

0 

5000 

32000 

88000 

156000 

226000 

V. 


EXHIBIT  8-4.  SPARES  SUMMARY  BUDGETS  TABLE 


by  multiplying  the  annual  number  of  repairs  times  the  ORU’s  unit  repair  cost.  It 
then  sums  that  product  for  all  ORUs  by  year  and  across  all  criticalities.  Unlike 
spares  budgets  that  spread  the  procurement  over  several  years,  the  repair  budgets 
assume  all  expenditures  affect  the  fiscal  year  during  which  the  broken  ORU  enters 
the  repair  process.  As  we  subsequently  discuss,  the  number  of  repairs  is  based  upon 
the  spares  calculation  while  a  component  of  the  repair  costs  is  an  exogenous 
assumption  entered  by  the  user. 

The  M-SPARE  model  estimates  annual  repairs  by  summing  all  repair  actions 
initiated  in  the  previous  12  months,  starting  at  the  most  recent  laimch  month  Eind 
moving  backward.  [The  launch  month  is  the  month  that  is  one  logistic  cycle  from  the 
end  of  the  year  and  is  the  point  at  which  the  model  estimates  annual  spares 
requirements  (see  Chapter  4).]  M-SPARE  estimates  repair  actions  by  first 
estimating  total  failures  (random  and  wear  related)  and  then  subtracting  estimated 
condemnations  (random  and  wear  related). 

The  M-SPARE  model  estimates  repair  cost  by  multiplying  the  ratio  of  the 
repair  cost  to  the  procurement  cost  times  the  ORU's  procurement  price.  Through 
analysis  of  Spacelab  historical  repair  data,  we  estimate  that  repair  ratio  to  be 
28  percent  (see  Appendix  B).  The  user  can  modify  the  repair  ratio  as  well  as  the  ratio 
that  splits  total  repair  costs  into  labor  costs  and  material  costs  in  the  OPTIONS.RPT 
file  (see  Chapter  6). 
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Exhibit  8-5  displays  the  repair  estimates.  The  annual  repair  budget  is  the 
result  of  the  methodology  just  discussed.  The  table  also  displays  that  budget  split 
into  labor  and  material  components.  Next,  the  table  displays  total  number  of  repairs 
and  then  the  average  repair  cost  (the  repair  budget  divided  by  the  number  of  repairs). 
The  last  rows  in  Exhibit  8-5  present  the  sum  of  the  repair  budget  and  the  spares 
budget  (Exhibit  8-4).  If  you  enter  a  price  inflator  in  the  options  file,  the  model  will 
produce  a  table  similar  to  Exhibit  8-5  but  in  current-year  dollars. 


r: .  ^ 


SUMMARY  BUDGET  ESTIMATES  (THOUSANDS  OF  CONSTANT  1991  DOLLARS) 


Repair  +  Spares  ($K)  /FY: 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

Annual  Repair  Budget 

0 

0 

0 

0 

2181 

3528 

4098 

Labor  Repair  Costs 

0 

0 

0 

0 

1963 

3175 

3688 

Material  Repair  Costs 

0 

0 

0 

0 

218 

353 

410 

Average  Repair  Costs 

0 

0 

0 

0 

152 

157 

159 

Annual  Number  of  Repairs 

0 

0 

0 

0 

14 

22 

26 

Cumulative  Repair  Budget 

0 

0 

0 

0 

2181 

5710 

9807 

Annual  Repai r>Spares 

0 

20505 

80536 

61136 

51458 

43460 

33100 

Cumulative  Repai r+Spares 

0 

20505 

81041 

142177 

193636 

237095 

270195 

^  Repair  budget  *  ORU  repairs/yr  • 

Price  • 

0.280 

EXHIBIT  8-5.  REPAIR  AND  SPARES  SUMMARY  BUDGET  TABLE 


DETAILED  SPARES  REQUIREMENT  FILES  (OUT.RPT) 

The  other  output  file  (OUT.RPT)  that  M-SPARE  produces  presents  more 
detailed  model  inputs  and  spares  requirements  outputs.  The  data  are  first  separated 
into  different  criticality  codes,  then  into  model  year  runs.  For  each  criticality  code, 
the  file  contains  a  launch  schedule,  demand  summary,  QPA  profile,  and  user  input 
table  for  all  model  years.  It  presents  six  other  tables  that  are  repeated  by  model  year. 
At  the  end  of  the  file  is  the  resource  and  ground  packing  summary  table.  The 
different  table  locations  are  mapped  out  in  Table  8-1.  Descriptions  of  the  various 
tables  in  the  file  are  as  follows: 

•  Element  Launch  Schedule  Table.  Displays  the  name,  month,  and  year  of 
each  element  launch. 

•  QPA  Profile  Table.  Displays  the  total  QPA  by  month  and  model  fiscal  year. 
Each  ORU  is  in  a  separate  subtable. 
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•  Demand  Summary  Table.  Displays  mean  orbit  failures,  mean  broken 
spares,  replaced  condemnations,  and  VMR  by  model  fiscal  year.  Each  ORU 
is  in  a  separate  subtable. 

•  User  Inputs  and  Options  Table.  Shows  the  user  inputs  entered  and  the 
model  options  selected  from  the  OPTIONS.RPT  file. 

•  ORU  Input  Data  Table.  Shows  the  ORU  input  information  from  the 
MSPAREIN.RPT  file  for  each  model  year. 

•  Pass  Solutions  Table.  Shows  the  station  availability  and  resource 
information  at  the  solution  point  for  each  pass  of  the  model. 

•  Spares  Mix  for  Solution  Point  Table.  Shows  the  spares  requirements  (on 
orbit  and  ground)  for  the  best  pass  solution. 

•  Distributed  Systems  Results  Table.  Shows  the  availability  and  station 
resource  expenditures  disaggregated  to  a  distributed  system  level. 

•  Resource- Versus- Availability  Curve  Table.  Presents  the  data  used  for  the 
curve  in  tabular  form. 

•  Resource  Summary  Table.  Shows  the  weight  and  volume  of  Criticality 
Code  1  ORUs  stored  on  orbit  and  all  ORU  codes  resupplied  each  year. 

•  Annual  Ground  Packing  Volume.  Displays  the  ground  inventory  volume  of 
serviceable  spares,  i.e.,  the  working  spares  volume  on  inventory  shelves. 

Each  output  table  is  discussed  in  a  separate  subsection  of  our  guide  and  is 
identified  by  the  table  title. 

Element  Launch  Schedule  Table 

If  your  ORU  input  data  is  by  element  laimch,  the  model  produces  the  launch 
schedule  (see  Exhibit  8-6).  The  first  two  columns  in  this  table  displays  the  M-SPARE 
element  number  and  name,  which  corresponds  to  the  order  and  name  of  the  elements 
in  the  OPTIONS.RPT  file  and  the  ORU  input  file.  The  next  two  columns  present  the 
element  launch  dates  in  calendar  month  and  year  (the  information  you  entered  in  the 
OPTIONS.RPT  file).  The  final  two  columns  present  the  launch  by  fiscal  month  and 
year.  Since  most  people  use  calendar  timefi’ames  while  M-SPARE  uses  fiscal 
timeframes,  we  present  the  translation  for  you.  A  fiscal  timeframe  places  the  laimch 
3  months  later  than  calender  information. 
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TABLE  8-1 


TABLE  LAYOUT  OF  OUT.RPT  FILE 

Criticality  Code  1 

Element  Launch  Schedule  Table 
QPA  Profile  Table 
Demand  Summary  Table 
User  inputs  and  Options  Table 
First  Model  Year 

ORU  Input  Data  Table 
Pass  Solutions  Table 
Spares  Mix  for  Solution  Point  Table 
Distributed  Systems  Results  Table 
Resource-Versus-Availability  Curve  Table 
Second  Model  Year  (same  type  of  tables  as  first  year) 
• 

Criticality  Code  2  (same  type  of  tables  as  Code  1) 

Criticality  Code  3  (same  type  of  tables  as  Code  1) 

Resource  Summary  Table 

Annual  Ground  Packing  Volume  Table 


QPA  Profile  Table 

The  QPA  profile  presents  the  total  QPA  (summed  across  all  elements)  by  month 
and  model  fiscal  year  for  each  ORU  (see  Exhibit  8-7).  QPA  is  the  only  demand 
variable  that  changes  from  one  model  year  to  the  next.  Depending  on  the  format  of 
yotir  ORU  input  data,  the  QPA  could  change  each  fiscal  year  (i.e.,  each  row)  or  on  a 
specific  month  of  the  element  launch.  If  the  input  data  is  by  element  launch,  the  QPA 
profile  is  followed  by  a  list  of  QPA  quantities  by  element.  If  the  ORU  is  a  wear  item, 
the  simulation  input  file  (PREPIN.DAT)  contains  the  QPA  profiles. 
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EXHIBIT  8-6.  ELEMENT  LAUNCH  SCHEDULE  TABLE 


ORU# 

1 

EXAMPLE 

STATION 

ORU 

LogCycle 

-  180  NOT  a  wear  item 

QPA  BY 

MONTH 

(COL).  YEARS  (ROW) 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

1996 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

1997 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

1998 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

1999 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2000 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

2001 

4 

4 

4 

4 

4 

4 

6 

6 

6 

6 

6 

6 

2002 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

2003 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

2004 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

2005 

6 

6 

6 

6 

6 

6 

6 

6 

6 

6 

8 

8 

Element  # 

1 

2 

3 

Element  QPA 

2 

2 

2 

J 

EXHIBIT  8-7.  QPA  PROFILE  TABLE 


Demand  Summary  Table 

The  table  in  Exhibit  8-8  contains  detailed  demand  information  by  ORU  and  by 
model  year.  The  purpose  of  the  table  is  to  display  the  most  detailed  calculations  of 
the  model.  (You  might  want  to  skip  this  information  initially.)  Each  column  of  the 
ORU  matrix  corresponds  to  different  factors  such  as  the  mean  orbit  failures,  the 
mean  broken  spares  (number  of  unserviceable  ORUs),  the  replaced  condemnations, 
and  the  VMR.  We  discuss  each  variable  in  Chapter  4.  However,  if  the  ORU  uses  the 
wear  simulation,  we  discuss  those  factors  in  Chapter  10. 
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A 

AT 

ORU  1  EXAMPLE 

STATION 

ORU 

Model  YR 

Mean  Orbit  Mear 

Broken 

Replace  Condemn. 

VMR 

1990 

4.00 

4.00 

0.00 

1.00 

1997 

4.00 

6.00 

0.00 

1.00 

1998 

4.00 

8.00 

0.00 

1.00 

1999 

4.00 

8.00 

2.00 

1.00 

2000 

8.00 

12.00 

2.00 

1.00 

2001 

12.00 

14.00 

2.00 

1.00 

2002 

12.00 

21.00 

2.00 

1.00 

2003 

12.00 

23.00 

4.00 

1.00 

2004 

12.00 

24.00 

5.00 

1.00 

2005 

12.00 

24.00 

6.00 

1.00 

V 

J 

EXHIBIT  8-8.  DEMAND  SUMMARY  TABLE 


User  Inputs  and  Options  Table 

The  next  table  in  the  OUT.RPT  file  displays  user  inputs  from  the  query  session 
and  model  options  from  the  OPTIONS.RPT  file.  The  table  first  displays  the 
availability  and  resource  (price,  weight,  and  volume)  targets.  Remember,  a  target 
number  that  shows  a  string  of  9s,  indicates  you  entered  a  “0”  (do  not  consider)  for  the 
target  value  and  the  model  reset  it  to  a  maximum  value  to  implement  your  direction. 
The  last  lines  in  the  table  show  the  global  values  for  all  the  model  options. 

ORU  Input  Data  Table 

The  next  table  is  the  ORU  input  data  read  from  the  MSPAREIN.RPT  file.  The 
column  headings  of  the  table  are  similar  to  the  input  file  headings  defined  in 
Chapter  5,  but  with  four  modifications.  The  file  contains  only  the  first  20  characters 
of  the  name  field.  Mean  orbit  demand  is  the  mean  demand  in  a  logistics  cycle  for  all 
ORU  applications  for  a  specific  model  year  and  is  the  product  of  several  input  fields 
(see  Equation  4-8).  The  VMRs  from  the  ORU  input  that  are  less  than  1  are  slightly 
modified  so  that  the  binomial  distribution  produces  valid  results.  Mean  broken 
indicates  the  mean  number  of  unserviceable  (broken)  units  in  the  maintenance 
process  (see  Equation  4-6). 
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Pass  Solutions  Table 


A  pass  solution  is  the  point  on  the  resource-versus-availability  curve  at  which 
one  of  the  station  targets  is  exceeded.  The  pass  solutions  table  displays  the 
availability,  resources,  and  coefficients  for  each  pass  solution.  The  model  selects 
those  solutions  as  the  best  pass  (see  Exhibit  7-6  and  discussion).  The  best  pass  data 
are  repeated  at  the  bottom  of  the  pass  solutions  table  and  also  used  to  help  generate 
the  initial  spares  list  that  follows.  All  resources  are  cumulative  (for  past  and  present 
years). 

Spares  Mix  for  Solution  Point  Table 

The  key  model  output  is  the  mix  of  spares  that  maximizes  availability  given  a 
set  of  targets  and  resource  coefficients.  In  the  spares  mix  table  (see  Exhibit  8-9),  the 
spares  solution  point  on  the  resource-versus-availability  curve  is  given  first.  (With 
multiple  passes,  the  selected  solution  point  is  the  best  pass.)  Next,  the  table  lists  each 
ORU’s  name  and  respective  gross  spares  requirements  (both  on  orbit  and  on  the 
ground),  the  assets,  and  the  net  spares  requirements  (requirements  minus  assets). 
The  on-orbit  and  ground  spares  are  the  results  of  the  optimal  solution.  The  next 
column  is  the  ORU  PSN  (see  Chapter  4).  If  you  multiply  the  individual  PSNs 
together,  you  will  quantify  the  predicted  station  availability.  The  next  column  in  the 
spares  mix  table  is  the  annual  investment  price  (the  net  spares  times  the  unit  price) 
for  each  ORU.  The  next  columns  give  the  breakdown  of  the  asset  value.  “Assets” 
equal  previous  years’  gross  spares  minus  replaced  condemnations.  If  the  starting 
spares  option  (see  Chapter  6)  is  set  to  “0”,  the  model  ignores  previous  assets  (i.e., 
asset  position  is  set  to  0),  and  the  entire  spares  mixes  are  selected  in  that  year.  The 
last  columns  (not  displayed)  present  the  serviceable  ground  spares  that  we  will 
discuss  in  the  last  chapter  section. 

Distributed  Systems  Results  Table 

The  distributed  systems  results  table  is  a  more  detailed  breakdown  of  the 
station  solution  point  discussed  above  and  is  derived  in  a  similar  manner.  The  table 
in  Exhibit  8-10  shows  those  results  from  our  test  drive.  The  bottom  line  of  that  table 
gives  the  station  spares  solution  point  on  the  curve  (95.0)  as  well  as  the  cumulative 
prices,  weight,  and  volume  of  the  gross  spares  requirements  [Note:  The  price  value 
does  not  include  replaced  condemnations,  so  it  differs  from  other  price  values].  The 
table  displays  the  on-orbit  volume  and  weight  for  all  ORU  spares  (total)  and  for 


8-10 


s  s  s  s  s  s  s 


S  S  3  3  3  3  a 


=  MIX  FOR  SOLUTION  °OINT  =»  =  = 

CRITICALITY  '.JOE  1  YEAR  2000 


AVAILABIir 

95 

.03 

RESOURCE 

140579.80 

1 

t 

--Asset  Breakdown-;  " 

I  ....  . 

1 

INITIAL 

SPARES 

-  -  -  1 

1 

Last  Yrs 

Condemns 

ORU  NAME 

Orbit+Ground- 

Assets  - 

Net 

PSN 

SK 

SpareSoln 

Th isYr 

1 

"RADIATOR 

"  1 

1 

2 

0 

99.13 

0.0 

2 

0 

2 

"RFCS 

3 

1 

3 

1 

99.52 

3562.0 

3 

0 

3 

"BATTERY  ORU 

"  4 

4 

5 

3 

99.84 

3585.0 

5 

0 

4 

"BCDU 

•  6 

7 

8 

5 

99.68 

7440.0 

8 

0 

V 
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EXHIBIT  8-9.  SPARES  MIX  FOR  SOLUTION 


pressurized  spares  (an  ORU  with  a  1  for  the  “P/U”  field  in  the  ORU  input  data).  The 
weight  and  volume  units  are  in  pounds  and  cubic  inches  and  in  racks  (1  rack  equals 
1,000  pounds  or  77,760  cubic  inches).  The  table  also  lists  the  number  of  distinct 
ORUs  (“#  ORUs”),  and  the  cumulative  number  of  spares  selected  (“Spares”).  In  the 
final  column,  M-SPARE  presents  a  rough  approximation  of  the  improvement  in 
availability  if  the  model  considers  ORU  redundancy.  For  that,  the  model  adds  an 
extra  on-orbit  spare  to  every  redundant  ORU  (an  “R”  in  the  ORU  criticality  code  field 
in  the  ORU  input  data)  and  recalculates  its  PSN  and  the  availability. 

The  table  disaggregates  the  total  space  station  system  results  to  distributed 
systems.  The  distributed  systems  are  ORU  subsets  of  the  total  space  station  and  are 
defined  by  the  DIST  SYSTEM  field  of  the  ORU  input  data.  The  model  calculates  the 
system  results  for  each  ORU  subset  in  a  similar  manner  as  the  station  results.  For 
instance,  a  distributed  system  availability  is  the  product  of  its  ORU’s  PSN.  Each 
ORU  must  be  associated  with  a  single  distributed  system. 

Resource-Versus-Availabiiity  Curve  Table 

The  resource-versus-availability  curve  table  shows  all  the  points  that  make  up 
the  curve.  Point  by  pOi^  t  (spare  by  spare),  the  table  lists  the  station  availability, 
accumulated  resources,  and  the  ORUs  selected.  The  table  starts  with  the  current 
asset  position  or  all  spare  levels  at  0  (no  resources  expended  for  the  first  fiscal  year) 
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====OISTRIBUTED  SYSTEMS  RESULTS  === 


CRITICALITY  CODE 

1  FY  2000 

J 

--Weight-lbs-- 

[  I  -Volume 

-inch ■ 3- ] 

R 

’Extra 

SYSTEM 

AVAIL 

•PRICE 

Total  Pressure 

Total 

Pressure 

#ORUs 

SPARES 

Spare 

6 

97.6 

78202 

7617  0 

926992 

0 

8 

51 

97.6 

12 

97.3 

116262 

6680  0 

733836 

0 

18 

149 

97.3 

SYSTEM 

Number 

95.0 

of  Racks 

194464 

14297  0 

14.30  0.00 

1660828 

21.36 

0 

0.00 

26 

200 

95.0 

1  RACKS’  1000  lbs  or  77760  in'3  (45ff3) 

*  price  does  not  include  condemnations 

Average  System  Availability  and  Extra  SpareX 


97.48  97.48 


EXHIBIT  8-10.  DISTRIBUTED  SYSTEMS  RESULTS  TABLE 

and  ends  when  the  station  availability  reaches  99  percent  (the  maximum  availability 
set  in  the  OPTIONS.RPT  file). 

Resource  Summary  Table 

The  purpose  of  this  table  is  to  present  a  complete  picture  of  the  spares  weight 
(sometimes  referred  to  as  “upmass”)  and  volume  launched  into  space.  To  do  that  the 
model  estimates  the  weight  and  volume  for  two  resource  categories:  (1)  the  spares 
stored  on  orbit  usually  for  the  Criticality  Code  1  ORUs  (see  top  of  Exhibit  8-11)  and 
(2)  the  spares  “resupplied”  to  SSF  to  replace  failures  for  Criticality  Codes  1,  2,  and  3 
ORUs  (see  bottom  of  Exhibit  8-11).  We  discussed  the  weight  and  volume  of  spares 
stored  on  orbit  already  and  displayed  the  results  in  the  pass  solutions  table  and  the 
resource-versus-availability  curve  table.  We  will  now  discuss  the  weight  and  volume 
of  the  resupplied  spares. 

The  M-SPARE  model  assumes  that  if  a  failure  occurs,  the  next  shuttle  will 
resupply  the  station  with  a  spare  (if  available)  to  replace  the  failure.  That  is  true 
except  for  the  ORU  spares  stored  on-orbit.  With  those  spares,  astronauts  may  have 
already  replaced  the  failure  with  a  spare  from  the  on-orbit  inventory.  In  that  case, 
the  resupplied  spare  replenishes  the  on-orbit  inventory.  To  estimate  the  resupply 
weight  and  volume,  M-SPARE  multiples  an  ORU’s  average  number  of  failures  in  a 
year  times  its  unit  resource  requirement  and  then  sums  across  all  ORUs  for  all 
criticalities.  The  model  calculates  annual  failures  by  summing  all  failures  that  occur 
for  the  previous  12  months,  starting  at  the  most  recent  launch  month  and  moving 
backwards. 
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RESOURCE  SUMMARY  (VOLUME  &  WEI6HT/UPMASS) 


Station  Configuration  Fiscal  Year 

On-orbit  Spares  Resources 

1998 

199u 

2000 

2001 

Cumulative  Orbit  Spares  Volume: In '3 

0 

0 

1613500 

1264998 

Cumulative  Orbit  Spares  Weight:1bs 

0 

0 

13556 

11107 

Annual  Orbit  Spares  Weight:1bs 
Resupply  Resources  (Unit  Resource  * 

0 

Demands/Yr) 

0 

for  all  crit 

13556 

codes 

0 

Annual  Resupply  Weight, all  0RUs:1bs 

2329 

3726 

4308 

4832 

Annual  Resupply  Volume, all  0RUs:In'3 

254060 

411017 

457334 

490869 

V _ J 

EXHIBIT  8-11.  RESOURCE  SUMMARY  TABLE 

For  consistency,  M-SPARE  presents  the  on-orbit  weight  and  volume  estimates 
(as  well  as  price  estimates)  as  cumulative  values  for  past  and  present  years. 
However,  weight  estimates  really  are  somewhat  different  since  unused  launch 
capacity  in  1  year  cannot  be  applied  in  following  years.  (That  is  not  the  case  for 
volume  capacity.)  Thus,  for  some  applications,  it  is  appropriate  to  consider  annual 
values  (the  difference  between  successive  cumulative  values)  on-orbit  spares  weight. 
Thus,  Exhibit  8-11  also  presented  annual  values.  For  similar  reasons,  Exhibit  8-11 
presented  resupply  weight  and  volume  as  annual  estimates  rather  than  as 
cumulative  estimates. 

Annual  Ground  Storage  Packing  Volume  Table 

Ground-storage  packing  requirements  equal  the  volume  of  the  inventory  of 
serviceable  spares  on  the  ground,  i.e.,  working  spares  on  inventory  shelves.  The 
M-SPARE  model  estimates  that  value  by  multiplying  the  number  of  average  annual 
serviceable  units  on  the  groimd  by  the  unit  volume  of  each  ORU.  It  then  sums  that 
product  for  all  ORUs  and  across  all  criticalities  (see  Exhibit  8-12).  The  average 
serviceable  imits  on  the  ground  equal  the  ground  spares  minus  the  mean  number  of 
unserviceable  imits  (sg  minus  MB). 

The  model  also  estimates  a  possible  maximum  ground  packing  volume  so  that 
the  user  can  identify  likely  peaks  in  packing  requirements.  For  that,  the  model 
assumes  the  peak  requirements  occur  when  newly  procured  spares  arrive  at  KSC  and 
require  additional  storage.  Although  the  new  spares  (M-SPARE’s  net  spares)  may 


n 
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eventually  move  elsewhere,  this  estimate  assumes  the  worst  case  —  all  new  spares 
require  ground  storage  in  the  first  year.  For  that  estimate,  the  model  adds  net  spares 
to  the  existing  serviceable  units  on  the  ground.  To  approximate  existing  serviceable 
units  on  the  ground,  the  model  scales  down  the  average  serviceable  spares  by  the 
ratio  of  last  year’s  requirements  to  this  year’s  requirements. 


I ANNUAL  GROUND  PACKING  VOLUME  AND  GROUND  SERVICEABLE  SPARES ^ 


station  Configuration  Fiscal  Year 

1998 

1999 

2000 

2001 

2002 

Average  Ground  Serviceable  Spares 

Avg.  Ground  Serviceab1e+  Net  Spares 
Avg.  Pack  Volume :[#Serv*Vo1]  (In'3) 
Avg  Pack-^-Net  Spare  Volume:  (In'3) 

86 

110 

167S904 

1930150 

110 

121 

1917902 

2022547 

48 

86 

672775 

1176637 

81 

102 

1838385 

2284638 

63 

956007 

1280291 

EXHIBIT  8-12.  GROUND  PACKING  VOLUME  TABLE 


CHAPTER  9 


M-SPARE  USE  FOR  THE  PROGRAM  OPERATING  PLAN 


The  SSF  project  offices  primarily  uses  M-SPARE  to  produce  spares  estimates 
and  funding  estimates  for  their  annual  POP  cycle.  M-SPARE  produces  three  basic 
products  for  the  POP  cycle.  The  following  products  will  each  be  discussed  in  a 
separate  section: 

•  Spares  Requirements  Product.  For  the  first  POP  product,  M-SPARE 
estimates  what  spares  the  station  requires  to  reach  a  specified  availability 
target.  As  always,  the  mix  is  optimal  and  is  the  least  cost  mix  to  reach  the 
availability  target,  but  no  overall  funding  constraint  is  applied.  To  produce 
that  product,  the  user  enters  annual  availability  targets  and  the  model 
estimates  the  spares  requirements  (as  we  described  in  Chapter  1  and  in  the 
test  drive  in  Chapter  2). 

•  Constrained  Budget  Product.  For  the  next  POP  product,  the  user  specifies 
the  expected  annual  budgets  (POP  marks),  and  M-SPARE  determines  how 
many  spares  NASA  can  acquire  for  the  money.  We  will  discuss  this  product 
in  detail  since  it  is  more  complicated  to  generate  than  the  others. 

•  Development  and  Operational  Product.  This  product  produced  a  further 
breakdown  of  requirements  into  two  subcategories:  spares  requirement  that 
support  the  station  in  the  first  year  of  the  ORU’s  life  and  spares 
requirements  that  support  the  ORU  thereafter.  For  the  purpose  of  this 
guide,  we  term  those  two  subcategories  as  “Development”  and  “Operational” 
requirements,  respectively. 

For  all  POP  products  and  criticality  codes,  the  user  usually  runs  the  model  with 
the  ground-stock-only  option.  The  exception  usually  is  for  spares  designated 
Criticality  Code  1.  For  Criticality  Code  1,  the  user  usually  assumes  ground-stock- 
only  through  FY99  then  both  on-orbit  and  ground  stock  thereafter.  That  means  the 
user  selects  the  ground  option  through  FY99  and  then  selects  the  multiple-pass 
option  for  the  remaining  model  years.  We  will  now  discuss  each  of  the  M-SPARE 
products  in  greater  detail. 


9-1 


SPARES  REQUIREMENTS  PRODUCT 


For  the  spares  requirements  product,  the  model  determines  what  spares  NASA 
would  like  to  have,  given  only  an  availability  target  (i.e.,  no  funding  constraints). 
The  user  inputs  yearly  availability  targets  and  M-SPARE  generates  spares 
requirements  for  the  first  years  of  the  station’s  life  (e.g.,  FY96  through  FY04).  It  also 
estimates  the  corresponding  funding  requirements  for  the  next  9  fiscal  years  (e.g., 
FY94  through  FY02)  to  meet  those  specified  targets.  The  availability  targets  usually 
vary  by  criticality  code  —  an  availability  of  95  percent  for  Criticality  Code  1  and  an 
availability  of  85  percent  for  Criticality  Codes  2  and  3.  The  availability  targets  can 
also  vary  by  year  although  for  the  last  POP  cycle,  they  remained  constant.  For  more 
information,  see  the  overview  discussion  in  Chapter  1,  the  detailed  operating 
instructions  in  Chapter  7,  or  the  model  demonstration  in  Chapter  2. 

CONSTRAINED  BUDGET  PRODUCT 

For  the  constrained  budget  product,  the  user  specifies  annual  budgets  for  the 
next  9  fiscal  years  (the  POP  marks),  and  M-SPARE  determines  how  many  spares 
NASA  can  obtain  with  those  funds.  The  constrained  product  is  more  difficult  to 
produce  than  the  requirements  product  because  budget  estimates  are  t5rpically  an 
output,  not  an  input,  of  M-SPARE.  Though  M-SPARE  can  use  an  input  in  dollars, 
those  dollars  are  very  different  from  budget  dollars.  M-SPARE  requires  inputs  based 
upon  a  specific  fiscal  year  in  the  SSF’s  life  and  those  inputs  are  actually  the 
cumulative  spares  resources  (weight,  volume,  and  price).  M-SPARE  uses  cumulative 
price  because  station  availability  is  based  upon  the  entire  inventory,  not  just  the 
incremental  spares  delivered  for  the  year.  Budgets  are  incremental  actions  over 
several  years  that  eventually  result  in  spares  deliveries.  Thus,  the  budget  level 
determines  the  incremental  dollar  “lay-away”  plan  required  for  future  spares 
deliveries;  on  the  other  hand,  M-SPARE  price  inputs  are  the  cumulative  (past  and 
present)  investments  of  the  delivered  spares. 

Table  9-1  illustrates  the  distinction  between  the  price  input  and  the  budget 
output.  That  table  continues  our  single  ORU  example  stated  earlier  in  Table  l-2c. 
M-SPARE  requires  the  cumulative  price  as  input  (displayed  in  the  shaded  column)  to 
produce  that  annual  budget  (displayed  second  to  last  row).  If  the  PLT  in  our  example 
was  1  day  (or  NASA  paid  for  the  spares  on  the  delivery  day),  then  the  cumulative 
budget  (shaded  row)  would  equal  the  input  price.  If  the  PLT  was  1  year,  then  the 
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cumulative  budget  would  lag  1  year  behind  the  input  price.  But  since  the  PLT  is 
2  years  and  the  ORU  unit  cost  is  spread  over  both,  the  cumulative  budget  is  quite 
different  from  the  cumulative  price  until  the  last  year.  So,  the  model  must  convert 
the  POP  marks  into  input  price  so  that  M-SPARE  output  approximates  the  POP 
marks.  What  makes  that  process  complicated  is  that  a  POP  mark  in  FY95  can 
impact  two  different  model  years,  FY96  and  FY97.  In  addition,  each  ORU  can  have  a 
different  PLT  ( 1  to  5  years)  and  can  spread  the  unit  cost  over  that  PLT  differently 
(i.e.,  different  spread  vectors).  We  will  now  discuss  how  the  model  performs  the 
conversion. 


TABLE  9-1 

INVESTMENT  INPUT  VERSUS  BUDGET  OUTPUT 


FY96 

FY97 

FY98 

FY99 

Logistics  cycle 

_ 

H 

B 

B 

6 

B 

D 

Requirenients/LogCycle 

H 

8 

■ 

B 

11 

12 

13 

14 

Requirements/year 

■ 

8 

B 

12 

14 

Net  requirements/year 

■ 

8 

B 

B 

2 

2 

Outlays 

($000) 

FY94 

fY95 

FY96 

FY97 

FY98 

Cumulative 
price  input 

ForSSF  FY96 

600 

400 

14)06 

ForSSFFY97 

150 

100 

1,2S6 

ForSSF  FY98 

ISO 

100 

1,506 

‘=orSSFFY99 

150 

100 

1,756 

Annual  budget 

600 

550 

250 

250 

100 

Cumulative  budget 

•  iym 

How  to  Target  M-SPARE  to  Match  POP  Marks 

Our  objective  is  to  produce  spares  funding  estimate  by  year  that  are  within  the 
budget  POP  marks.  We  assume  that  the  user  knows  the  annual  POP  marks,  by  year, 
in  current-year  dollars  for  all  criticality  codes.  To  convert  POP  marks  to  cumulative 
price  inputs  the  user  performs  the  following  steps: 

•  If  you  do  not  use  an  M-SPARE  price  inflator  (see  Chapter  6),  deflate  the 
annual  POP  marks  from  the  current  year  to  constant-baseline-year  dollars 
(the  baseline  year  is  the  dollar  year  of  the  ORU  unit  prices).  If  you  want  to 
use  a  constant  price  inflator  for  all  model  years,  insert  it  into  the 
OPTIONS.RPT  file  and  the  model  deflates  che  POP  marks  automatically. 
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•  Disaggregate  your  POP  marks  into  marks  set  by  criticality  codes.  You 
might  want  to  split  the  budget  based  upon  some  fixed  ratio  (e.g.,  50  percent 
for  Criticality  Code  1  ORUs,  30  percent  for  Criticality  Code  2  ORUs,  and 
20  percent  for  Criticality  Code  3  ORUs)  or  perhaps  divide  the  total  POP 
budget  based  upon  the  results  of  the  M-SPARE  requirements  products 
discussed  earlier. 

•  Sum  the  previous  year’s  POP  marks  to  produce  cumulative  marks  by  fiscal 
year. 

•  Insert  the  cumulative  marks  into  the  OPTIONS. RPT  file  (see  Chapter  6). 

•  Run  the  model  using  availability  targets  to  generate  the  spares 
requirements  products  and  allow  the  model  to  “get  smart  enough”  to  make 
an  initial  guess  for  the  input  price. 

•  Rerun  the  model  using  the  “price  guess”  targets  (shaded  area)  generated  as 
part  of  the  total  annual  budgets  by  model  run  year  table  (see  Exhibit  9-1). 
That  price  guess  is  the  cumulative  investment  that  should  reproduce  the 
POP  marks. 

By  rerunning  the  model  a  few  times  using  the  latest  price  guess,  model  results  should 
converge  towards  the  cumulative  POP  marks. 

Targeting  Methodology 

The  table  in  Exhibit  9-1  displays  the  methodology  the  model  uses  to  convert 
POP  marks  into  input  price  targets  (some  of  the  right-hand  columns  are  not 
displayed).  The  top  part  of  the  exhibit  is  the  latest  M-SPARE  output,  and  the  bottom 
part  is  what  M-SPARE  g.  erses  the  output  needs  to  be  to  match  the  POP  marks.  The 
model  targets  each  criticality  code  separately.  We  first  run  the  model  based  upon 
availability  targets  to  determine  how  the  model  spreads  net  spares  requirements 
dollars  over  previous  fiscal  years.  In  our  exhibit,  we  assume  Criticality  Code  1  ORUs, 
so  we  used  a  95  percent  ground  (Grd)  availability  in  the  first  2  years  and  then  a 
95  percent  station  (Orb)  availability  in  the  remaining  years.  The  top  part  of 
Exhibit  9-1  presents  the  resulting  output.  The  first  columns  of  Exhibit  9-1  present 
the  output  availabilities. 

The  top  part  of  Exhibit  9-1  aiso  J^oplays  the  dollar  outputs  by  model  year  (the 
rows)  and  the  budget  estimates  (the  columns).  All  values  are  in  thousands  of 
constant  dollars.  Notice  for  model  year  FY98,  the  model  spreads  dollars  back  to 
FY95,  FY96,  and  FY97.  That  spread  is  generate  when  M-SPARE  takes  an  ORU’s  net 
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f. . . . 

Total  Annual  Budgets  by  Modal  Run  Year  for  CRITICALITY  CODE  1 
A11  Values  in  thousands  of  constant  dollars 
(Purpose:  Helps  you  get  model  budgets  equal  to  POP  Marks) 


BUDGET 

ESTIMATE 

FROM  ‘LAST 

•  MODEL 

RUN 

Availabil ity/Eiscal  Year 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

Grd  96. 2/Model  Year>  1998 

0 

20505 

50526 

24570 

0 

0 

0 

Grd  95. 2/Model  Year>  1999 

0 

0 

10010 

21874 

10133 

0 

0 

Orb  95.1/Model  Year«  2000 

0 

0 

0 

14493 

29411 

13166 

0 

Orb  95.1/Model  Year>  2001 

0 

0 

0 

0 

10708 

22406 

10178 

Orb  95.1/Model  Year>  2002 

0 

0 

0 

0 

0 

7146 

13489 

Orb  95. 0/Mode  1  Year>  2003 

0 

0 

0 

0 

0 

0 

6700 

Orb  95.1/Model  Year-  2004 

0 

0 

0 

0 

0 

0 

0 

Orb  9S.l/Mode1  Year-  2005 

0 

0 

0 

0 

0 

0 

0 

Annual  Model  Budget 

0 

20505 

60536 

60936 

50252 

42718 

30367 

Annual  POP  MARKS 

0 

0 

5000 

27000 

56000 

68000 

70000 

Cumulative  Model  Budget 

0 

20505 

81041 

141977 

192229 

234947 

265314 

Cumulative  POP  MARKS 

0 

0 

5000 

32000 

88000 

156000 

226000 

Ratio  (Cum.  POP/Model)  0 

.0000 

0.0000 

0.0617 

0.2254 

0.4578 

0.6640 

0.8518 

BUDGET 

ESTIMATE 

FOR  ‘NEXT* 

MODEL  RUN 

Year  StMSS  Factor  * 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

1998  9.1  0.00 

0 

0 

0 

0 

0 

0 

1999  aesa?  0.50 

0 

0 

5000 

10926 

5062 

0 

2000  9429#  1.11 

0 

0 

0 

16074 

32620 

14603 

0 

2001  198349  1.71 

0 

0 

0 

0 

18318 

38329 

17411 

2002  311999  2.00 

0 

0 

0 

0 

0 

14303 

27000 

2003  393731  2.00 

0 

0 

0 

0 

0 

13410 

2004  39S779  2.00 

0 

0 

0 

0 

0 

0 

2005  339494  2.00 

0 

0 

0 

0 

0 

0 

Next  Cumulative  Budget 

0 

0 

5000 

32000 

88000 

155235 

213056 

Cumulative  POP  Marks 

0 

0 

5000 

32000 

88000 

156000 

226000 

Ratio  (Cum.  POP/Model)  999 

.0000 

999.0000 

1.0000 

1.0000 

1.0000 

1.0049 

1.0608 

SUMMARY  BY  MODEL  YEAR 

1998 

1999 

2000 

2001 

2002 

2003 

2004 

Next  Price  Guess 

0.1 

20987.3 

84284.2  158343.2 

211288.6 

262730.9 

305778.6 

Last  Price  Guess 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

Last  Availability  Output 

96.2 

95.2 

95.1 

95.1 

95.1 

95.0 

95.1 

\Average  Availability 

95.24 

A 


EXHIBIT  9-1.  TARGETING  M-SPARE  TO  POP  MARKS 


spares  reqmrements  and  applies  the  ORlTs  spread  vector.  Exhibit  9-1  is  the  sum  of 
that  spread  for  all  Criticality  Code  1  ORUs. 

The  model  next  displays  the  annual  model  budget  (the  sum  of  the  columns)  and 
the  cumulative  model  budget  outputs  (the  sum  of  the  previous  and  current  annual 
values).  For  comparison,  the  model  also  displays  the  annual  and  cumulative  POP 
marks  you  entered  in  the  OPTIONS.RPT  file  earlier.  The  model  next  displays  the 
ratio  of  the  cumulative  POP  marks  to  the  cumulative  model  budget.  Our  objective  is 
to  make  sure  that  ratio  is  greater  than  or  equal  to  1  (i.e.,  the  model  funding  is  always 
within  the  budget). 
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To  do  that  for  our  example,  we  must  reduce  certain  model  year  budgets.  We 
assume  that  the  spread  of  dollars  by  model  year  does  not  significantly  change  from 
one  run  to  the  next.  So  to  reduce  a  model  year  budget,  we  must  reduce  all  spread 
values  by  the  same  factor.  M-SPARE  reduces  each  model  year  until  all  ratios  are 
near  1. 

The  bottom  of  Exhibit  9-1  displays  the  result  of  multiplying  the  previous  spread 
values  (the  corresponding  top  part  of  the  exhibit)  by  a  “factor”  (third  column)  so  that 
the  resulting  ratios  (cumulative  POP  mark/cumulative  model  budget  —  bottom  row) 
for  the  affected  years  approximately  equals  1.  The  model  starts  with  the  first  year 
(FY98)  and  adjusts  the  factor  until  of  the  appropriate  cumulative  ratios  (FY95,  FY96, 
and  FY97)  are  greater  than  or  equal  to  1.  Since  the  POP  mark  is  0  in  FY95,  the  factor 
must  equal  0  and  all  spread  values  become  “0”.  The  model  then  moves  to  the  next 
model  year,  looks  at  the  new  ratios,  and  repeats  the  process.  In  some  cases,  the  factor 
is  less  than  0  (i.e.,  the  model  reduced  the  funds),  and  in  other  cases,  it  is  greater  than 
0  (i.e.,  the  model  increased  the  funds).  The  resulting  ratios  are  never  less  than  1, 
though  sometimes  greater  than  1.  The  latter  assumes  that  NASA  can  apply  POP 
dollars  in  later  years. 

Once  the  ratios  are  approximately  equal  to  1,  the  model  sums  the  current  and 
previous  spread  values  to  produce  the  price  guess  (see  the  shaded  area  of  Exhibit  9-1). 
You  then  rerun  the  model  using  that  price  guess.  For  our  example,  enter  the  price 
guess  values  of  0.1,  21009,  83229,  etc.,  as  the  M-SPARE  price  targets  for  model  years 
FY98,  FY99,  FYOO,  etc.,  respectively.  (You  must  enter  a  target  of  “0.1”  instead  of  a 
“0”  for  FY98  because  M-SPARE  assumes  a  0  means  the  maximum  resource,  and  you 
really  want  a  small  value  to  prevent  the  model  from  selecting  spares.)  Repeating 
that  process  should  produce  budgets  close  to  the  POP  marks  within  a  few  iterations. 
However,  as  you  get  close  to  matching  the  POP  marks,  you  may  need  to  override  the 
price  guess  feature  and  fine  tune  the  estimates  if  the  price  guess  goes  astray.  One 
way  to  fine  tune  the  price  guess  is  with  our  next  model  feature. 

Spares  Selection  Based  Upon  PLT 

The  M-SPARE  model  has  a  feature  (accessed  through  the  user  queries  described 
in  Chapter  7)  that  lets  the  user  specify  what  ORUs  the  model  selects  on  the  basis  of 
the  ORU’s  PLT.  In  that  way,  M-SPARE  selects  spares  with  shorter  PLTs  as  soon  as 
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funds  become  available.  [Note:  This  feature  usually  generates  a  nonoptimal  spares 
mix  as  we  will  discuss.] 

You  may  note  that  in  the  example  shown  in  Exhibit  9-1,  M-SPARE  does  not 
select  spares  until  1999  (the  first  fiscal  year  when  the  price  guess  is  greater  than 
zero).  That  delay  is  because  ORUs  with  3-year  PLTs  require  3  years  of  available 
outlays  (FY96,  FY97,  and  FY98).  However,  M-SPARE  could  select  ORUs  with 
shorter  PLTs.  For  that  selection,  M-SPARE  lets  the  user  specify  ORU  selection  based 
upon  PLT.  The  actual  model  dialog  is,  “Enter  the  maximum  PLT  (months)  for  spare 
ORUs.”  For  instance,  if  the  model  year  is  FY98  and  the  POP  budget  only  has  funds  in 
FY96  and  FY97,  the  user  enters  a  “24”  and  the  model  only  selects  ORUs  with  a  24- 
month  PLT  or  less.  ORUs  with  greater  PLTs  require  funds  that  are  not  available, 
i.e.,  they  require  FY95  dollars,  and  thus  the  M-SPARE  model  does  not  select  them. 

The  user  must  enter  a  price  (dollar)  target,  not  an  availability  target  when 
using  this  option  since  M-SPARE  does  not  select  spares  for  ORUs  whose  PLTs  are  too 
large,  the  ORU’s  PSN  and  resulting  system  availability  are  very  low.  If  the  user 
enters  an  availability  target  with  this  option,  the  model  selects  too  many  spares  for 
the  ORUs  with  shorter  PLTs  and  still  never  reaches  the  target.  A  price  target  forces 
M-SPARE  to  stop  selecting  spares  when  the  dollars  run  out.  A  second  area  of  caution 
is  not  to  use  the  minimum  spares  option  when  using  a  maximum  PLT  because 
M-SPARE  selects  the  minimum  spares  regardless  of  the  PLT. 

A  final  area  of  concern  about  using  PLT  selection  is  that  you  procure  ORUs  with 
shorter  PLTs  sooner  and  those  with  longer  PLTs  later.  That  condition  occurs  because 
the  ORUs  with  shorter  PLTs  may  use  up  the  funds  needed  to  start  procuring  those 
with  longer  PLTs.  Thus,  you  may  improve  availability  slightly  in  the  earlier  years 
but  delay  reaching  your  availability  targets  in  the  later  years. 

DEVELOPMENT  AND  OPERATIONAL  PRODUCT 

The  model  user  may  require  further  breakdown  of  spares  requirements  into 
what  we  term  development  and  operational  spares.  Development  spares  support  the 
station  in  the  first  year  of  an  ORU’s  life,  and  operational  spares  support  the  ORU 
thereafter.  To  estimate  the  split,  the  model  first  calculates  spares  and  budgets 
requirements  as  we  described  in  Chapter  8  (for  this  chapter  section,  we  call  them 
“aggregate”  requirements).  Then,  it  determines  the  percentage  of  spares  and 
resulting  budget  requirements  associated  with  development.  Finally,  the  model 
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subtracts  development  budgets  from  aggregate  budgets  to  estimate  operational 
budgets. 

To  produce  that  disaggregation,  the  user  sets  the  funding  split  option  in  the 
OPTIONS.RPT  file  to  “1”.  The  model  then  produces  two  additional  tables  in  the 
BUDGET.RPT  file  similar  to  the  net  spares  requirements  (but  displays  only 
development  spares)  and  the  spares  summary  budget  table  (see  Chapter  8).  The 
following  steps  are  required  for  the  disaggregation. 

The  M-SPARE  model  first  calculates  total  spares  requirements  over  time  given 
an  availability  or  price  target.  That  calculation  is  standard  for  all  options. 


Next,  M-SPARE  determines  what  portion  of  the  total  spares  are  development 
spares.  Once  each  year,  it  takes  the  ratio  of  the  total  QPA  of  elements  launched 
within  that  year,  to  the  QPA  for  elements  previously  launched  (the  top  right  and  top 
left  side  of  Exhibit  9-2,  respectively).  M-SPARE  generates  those  tables  (see  QPA 
profile  table  in  OUT.RPT  file)  based  upon  the  element  launch  schedule.  We  assumed 
2  launches  for  this  ORU  in  Months  3  and  9  for  FY97.  The  element  QPA  for  both 
laimches  equaled  2.  The  shaded  column  in  the  exhibit  is  the  QPA  ratio  for  the  launch 
Month  7.  M-SPARE  uses  that  month  for  the  QPA  ratio  because  it  estimates  gross 
spares  requirements  at  that  month. 


ORU#  1DBSICCANT(S0RBENTBED(CRM)  LogCyele  =  136  NOT  •  wMr  item 
QPA  BY  MONTH  (COU.  YEARS  (ROW) 

1  23466789  10  11  12  Dwelop  1  2  3  4  5  6  7  8  9  10  11  12  Dwel.  at  Yr  End-LC^  7 


1996  0  0  0 

1997  0  0  2 

1998  4  4  4 

1999  4  4  4 

2000  4  4  4 

2001  4  4  4 


0  0  0  0  0  0 
2  2  2  2  2  4 

4  4  4  4  4  4 
4  4  4  4  4  4 
4  4  4  4  4  4 
4  4  4  4  4  4 


0  0  Develop  0  0 

4  4  Develop  0  0 

4  4  Develop  4  4 

4  4  Develop  0  0 

4  4  Develop  0  0 

4  4  Develop  0  0 


0  0  0  0  0  0  0 

2  2  2  2  2  2  4 

2  2  2  2  2  2  0 

0  0  0  0  0  0  0 

0  0  0  0  0  0  0 

0  0  0  0  0  0  0 


000  idMO 
4  4  4  IMOO 
0  0  O  0M0» 
0  0  0  ooew 

0  0  0  <UXN» 
0  0  0  ODMO 


Elnunt#  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15 
EIcmcntQPA  2  02000000000  0  0  0 
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EXHIBIT  9-2.  ESTIMATING  THE  PROPORTION  OF  DEVELOPMENT  SPARES 
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The  M-SPARE  model  then  multiplies  the  ORU  QPA  ratio  times  the  gross  spares 
requirements  to  estimate  the  development  spares  by  fiscal  year.  That  result  is  given 
in  the  table  that  follows  the  standard  budget  reports  and  is  labeled  development  net 
spares  requirements  (identical  in  format  as  the  aggregate  net  spares  including 
replaced  condemnations  table  discussed  in  Chapter  8).  The  model  also  ensures  that 
the  development  net  spares  does  not  exceed  the  aggregate  net  spares  requirements. 

For  example,  if  an  ORU  gross  and  net  spares  equals  10  and  4,  respectively,  and 
the  QPA  ratio  equals  0.5,  the  model  assumes  that  50  percent  of  the  gross  spares  (i.e., 
5  spares)  is  for  development.  However,  since  the  model  net  spares  equals  4  for  the 
current  year,  M-SPARE  assumes  that  4  is  the  maximum  number  of  development  net 
spares.  The  model  then  calculates  budgets  by  multiplying  the  development  net 
spares  by  the  ORU  spread  vectors  to  produce  the  development  spares  budgets  table. 

Finally,  the  model  subtracts  the  development  budget,  summed  across  ORUs, 
from  the  aggregate  spares  budget  to  produce  the  operational  budget.  M-SPARE 
displays  the  development,  operational,  and  aggregate  totals  (annual  and  cumulative) 
at  the  bottom  of  the  BUDGET.RPT  file. 

Development  and  Operational  Budgets  by  Element  Launch 

The  model  further  extends  the  development  and  operational  budgets  by 
subdividing  both  into  element  launch  budgets  (see  Exhibit  9-3).  That  estimate  gives 
a  rough  idea  of  the  funds  required  to  support  each  launch.  For  those  element  budgets, 
the  model  multiplies  an  ORU’s  development  or  operational  budget  (just  discussed)  for 
a  particular  year  by  a  QPA  ratio.  For  the  development  budget,  the  QPA  ratio  is  the 
relationship  between  the  element  QPA  (bottom  line  of  Exhibit  9-2)  for  elements 
launched  within  the  year  (i.e.,  between  the  current  and  previous  launch  months)  and 
the  total  QPA  for  all  element  launchings  within  the  year  (QPA  at  the  launch  month: 
top  right  side  of  Exhibit  9-2).  For  operational  budgets,  the  QPA  ratio  is  the 
relationship  between  the  element  QPA  (bottom  line  of  Exhibit  9-2)  for  elements 
launched  within  or  before  the  year  (i.e.,  before  the  previous  launch  month)  and  the 
total  QPA  for  all  element  launchings  within  or  before  the  year  (top  left  side  of  Exhibit 
9-2). 
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'  Budget  Values  below  in  Thousands  of 
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0 
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0 
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0 
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0 

0 

0 

0 

0 
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0 
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"Annual  Operational 
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5  70 

2690 

10068 

11669 
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EXHIBIT  9-3.  ELEMENT  LAUNCH  BUDGETS 
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CHAPTER  10 


THE  WEAR  PREPROCESSOR 


INTRODUCTION 

So  far  we  have  assumed  the  MTBF  specifies  the  likelihood  of  an  ORU  random 
failure.  However,  an  ORU  also  fails  after  being  in  operation  for  some  period  of  time. 
It  simply  wears  out.  The  average  period  of  time  it  takes  to  wear-out  is  the  mean 
“wear”  life  of  an  ORU  and  is  specified  in  the  ORU  data  base  (see  Chapter  5).  For  most 
ORUs,  that  wear  life  is  20  to  30  years;  thus,  they  do  not  wear  out  within  the  model 
time  horizon  of  15  years  (i.e.,  the  maximum  number  of  model  years).  For  some  ORUs, 
however,  the  wear  life  is  shorter  and  related  failures  may  occur  in  the  model  time 
horizon.  For  those  ORUs,  we  use  the  “wear”  preprocessor  to  simulate  both  types  of 
failures  (those  that  are  random  and  those  in  which  an  ORU  wears  out)  and 
automatically  pass  the  aggregate  information  to  M-SPARE. 

The  “wear”  preprocessor,  from  the  M-SPARE  interface  (see  Chapter  2),  selects 
and  prepares  the  proper  ORU  input  data  for  M-SPARE.  It  selects  the  ORU  if  the 
mean  life  of  an  ORU  minus  the  “wear”  wake  (set  in  the  OPTIONS.RPT  file  described 
in  Chapter  6)  is  less  than  the  maximum  number  of  model  years.  For  instance,  if  the 
ORU  has  a  mean  life  of  19  years,  failures  attributable  to  wear  may  occur  as  early  as 
14  years  into  the  ORU  life  (i.e.,  a  “wear”  wake  of  5  years).  Since,  the  maximum 
number  of  model  years  is  15,  failures  from  wearing  out  may  affect  the  model 
calculation,  and  the  preprocessor  is  automatically  used.  You  run  the  wear 
preprocessor  initially  and  again  whenever  you  update  the  ORU  data  base  or  the 
launch  schedule  (in  the  OPTIONS.RPT  file). 

Exhibit  10-1  displays  two  preprocessor  options  once  you  select  the  “Wear” 
option  from  the  M-SPARE  interface.  If  you  select  “Automatic”,  the  preprocessor 
selects  the  proper  ORUs,  generates  the  necessary  input  data,  and  runs  the 
preprocessor.  If  you  select  “Manual”,  the  preprocessor  gives  you  a  chance  to  override 
simulation  input.  It  will  bring  you  directly  to  the  editor  and  the  preprocessor  input 
file  (described  later  in  this  chapter),  allowing  you  to  change  any  of  the  inputs.  When 
finished,  press  the  “ALT-X”  key  combination  to  save  the  file  and  complete  the 


execution  of  the  preprocessor.  Before  running  the  manual  option,  you  should  run  the 
automatic  option  once  so  that  the  input  file  is  generated  in  the  proper  format.  Then 
you  can  run  the  manual  option  and  make  your  edits.  The  purpose  of  the  manual 
option  is  to  allow  you  to  perform  sensitivity  analyses  (such  as  changing  the 
condemnation  assumptions)  with  the  simulation. 


EXHIBIT  10-1.  OPTIONS  FOR  THE  WEAR  PREPROCESSOR 


The  preprocessor  calculates,  by  month,  the  mean  demand  (due  to  random  and 
wear-out  failures),  the  VMR  of  demand,  and  the  cumulative  average  condemnations. 
M-SPARE  automatically  uses  those  data  in  a  multi-ORU  optimization  run  to 
determine  the  spares  mix,  location,  and  budgets.  There  may  be  several  ORU  unite 
and  the  number  may  change  over  time  as  SSF  is  built  up.  We  will  now  discuss  the 
logic,  inputs,  processing,  and  outputs  of  the  preprocessor. 

PROGRAM  LOGIC 

The  preprocessor  is  a  Monte  Carlo  simulation.  For  each  installed  unit  of  the 
ORU,  the  simulation  uses  an  exponential  probability  distribution  to  estimate  the 
time  of  the  next  random  failure  and  uses  another  probability  distribution  (normal  or 
Weibull)  to  estimate  the  time  the  next  unit  will  wear  out.  The  smaller  time  is 
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selected  as  the  time  of  the  next  failure.  The  simulation  then  determines 
probabilistically  whether  the  failure  can  be  repaired  or  whether  it  must  be 
condemned.  It  is  assumed  there  is  a  probability  {cp)  that  a  random  failure  results  in 
condemnation.  After  N  random  failures  the  unit  must  be  condemned.  Of  course,  cp 
may  be  0,  N  may  be  0  (meaning  no  deterministic  condemnation  mode),  or  both  may  be 
0  (the  ORU  is  always  repaired). 

Similarly,  there  is  a  probability  that  a  worn  out  unit  will  be  condemned  and 
after  M  wear-out  failures  the  unit  must  be  condemned.  Usually  the  cp  that  a  unit  will 
wear  out  is  larger  than  a  random  cp,  and  in  some  cases  (batteries,  for  example)  the 
probability,  cp,  that  a  unit  will  wear  out  is  equal  to  1. 

If  the  first  failure  is  a  random  failure  that  does  not  result  in  a  condemnation, 
the  simulation  then  draws  the  time  to  the  next  random  failure  and  keeps  track  of  tne 
fact  that  there  has  been  one  repair  of  a  random  failure.  The  simulation  compares  the 
time  of  the  next  random  failure  to  the  time  the  unit  was  expected  to  wear  out,  selects 
the  smaller  time,  and  repeats  the  procedure  described  above  to  determine  whether 
there  should  be  a  condemnation.  An  analogous  procedure  is  followed  for  a  failure  due 
to  wear  that  does  not  result  in  a  condemnation  and  establishes  a  new  time  that  it  will 
wear  out.  When  the  unit  is  condemned  because  of  a  random  failure  or  because  it  wore 
out,  a  new  unit  of  the  ORU  is  installed  and  the  failure  and  age  counters  are  reset  to  0. 

INPUT 

The  data  for  the  program  is  kept  in  an  ASCII  file  called  PREPIN.DAT 
developed  from  the  MSPAREIN.RPT  and  the  OPTIONS.RPT  files.  The  first  three 
lines  (not  used  by  the  program)  contain  headings  to  assist  the  user  in  identifying  the 
data  elements  on  the  next  line.  Similarly,  the  next  three  lines  (also  not  used  by  the 
program)  contain  headings  to  assist  the  user  in  identifying  the  data  elements  on  the 
succeeding  rows  —  one  row  for  each  ORU. 

A  sample  input  data  file  is  shown  in  Exhibit  10-2.  Note  that  each  ORU 
name/identification  is  assumed  to  be  15  characters  in  length,  but  the  other  fields  may 
be  of  any  length.  The  program  interprets  a  space  as  a  delimiter  between  numeric 
fields.  There  must  be  at  least  one  space  between  fields,  and  a  value  of  0  must  be 
entered  for  a  numeric  value  of  0  (not  blank  as  it  would  be  in  fixed  format  FORTRAN 
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input).  If  no  decimal  point  is  provided,  the  decimal  point  is  assumed  to  be  at  the  right 
of  the  field.  Entering  a  decimal  point  overrides  this  default. 


input  to  condemnations  and  demand  preprocessor  •••••••' 

> - - - GLOBAL  PARAMETERS . . ---! 

WEIBULL  W/Con  Years  Delays  Seed  lYReps  Print  Mth/Period  lYMth  Input 
1  1  15  0.0  31313  1000  0  12  180 


ORU  DATA 


NAME 

--MTBF(Years)-- 

;wear; 

SO 

-RANDOM- 

■;-MEAR- 

1 

1  _  _ 

1 

Cumulative  i 

OPA 

» 

by  1 

Ronth 

-- 

RANDOM 

WEAR 

cp 

C# 

cp 

CiK 

Wgt 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

BATTERY  ORU 

41.8524 

5.00 

10  1 

.00 

0 

1 

1 

356 

24 

24 

24 

24 

24 

24 

24 

24 

24 

24 

SAMPLE  ORU 

4.000 

6.00 

10  0 

.60 

4 

1 

1 

SO 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

EXHIBIT  10>2.  SAMPLE  INPUT  DATA  FILE 


The  first  line  of  numerical  data  applies  to  all  ORUs  with  each  field  defined  as 
follows: 

•  WEIBULL.  There  are  two  choices  for  the  distribution  of  units  wearing  out: 
“1”  equals  Weibull  (the  M-SPARE  default  assumption)  and  “0”  equals 
normal.  The  same  distribution  is  used  for  all  OP.Us,  but  the  parameters  may 
vary  by  ORU, 

•  W/Con.  When  a  value  of“0”  is  entered,  repairable  item  demand  is  displayed 
in  the  output.  This  is  useful  if  the  user  wants  to  compute  spares  for 
condemnations  separately.  If  a  “1”  is  entered  (the  M-SPARE  default 
assumption),  repairable  demand  is  combined  with  demands  that  result  in 
condemnations  (W/Con).  The  usage  of  this  input  variable  is  discussed  in 
more  detail  in  the  utilization  of  preprocessor  input  in  the  last  section. 

•  Years.  This  is  the  number  of  years  for  which  output  is  desired.  It  is  limited 
to  30  years  or  less.  If  the  number  of  years  of  output  exceeds  the  #Mth  Input 
(described  below),  the  program  assumes  that  the  units  of  each  ORU  (QPA)  in 
the  last  month  remain  constant  until  the  end  of  the  last  year. 

•  Delays.  This  is  the  delay  between  the  time  a  failure  occurs  and  the  time 
when  the  condemnation  determination  is  made. 

•  Seed.  This  is  a  random  number  seed  used  to  draw  failure  times  and  is  eui  odd 
number  less  than  32767. 

•  #Reps.  This  is  the  number  of  repetitions  desired  of  the  simulation  for  all 
units  of  the  item.  A  repetition  is  the  number  of  demands  from  0  to  15  years 
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for  all  units  of  the  item.  A  value  of  1000  is  suggested,  but  larger  values 
should  be  used  if  ORUs  have  large  MTBFs. 

•  Print.  This  is  a  print  control  so  that  the  user  can  check  the  program  logic. 
Normally  the  print  detail  switch  is  set  to  “0”  (or  blank).  If  print  equals  “1,” 
the  screen  shows  each  demand  for  each  unit  of  the  ORU,  whether  the 
demand  was  the  result  of  a  random  failure  or  a  worn  out  unit  and  whether  a 
condemnation  resulted.  This  is  done  for  the  first  repetition  of  the  simulation 
on  each  item. 

•  Mth/Period.  The  number  of  months  per  period  is  used  to  combine  monthly 
input  data  into  output  data  by  period. 

•  ^Mth  Input.  The  number  of  months  for  which  the  QPA  of  each  ORU  is 
entered  below  in  the  detail  data  by  ORU. 

The  next  inputs  are  for  each  ORU.  An  unlimited  number  of  ORUs  may  be 
entered,  but  graphs  are  prepared  only  for  the  first  ORUs.  The  simulation  directly 
obtains  most  of  the  ORU  data  that  follow  from  the  MSPAREIN.RPT  data  base. 

•  NAME.  This  is  any  identification  of  the  ORU  in  a  15-character  field. 

•  MTBF  (Years)  RANDOM.  This  is  the  random  failure  mean  (in  years)  with 
an  exponential  distribution. 

•  MTBF  ("Years.)  WEAR.  This  input  provides  the  MTBF  (in  years)  mean  life 
caused  by  wear  for  the  Weibull  or  normal  distribution,  as  specified  in  the 
first  data  element  on  the  top  line.  (For  the  Weibull,  the  simulation  develops 
its  parameters  based  upon  the  mean.)  For  preventive  maintenance  ORUs, 
this  value  is  the  replacement  frequency. 

•  WEAR  SD.  This  is  a  the  standard  deviation  (in  years)  for  the  normal  or  the 
shape  parameter  for  the  Weibull  distribution  of  failures  caused  by  wear. 
(For  the  Weibull,  smaller  values  result  in  larger  standard  deviations.) 

•  RANDOM  cp.  This  is  a  random  failure  condemnation  probability 
(MSPAREIN.RPT  fraction  3  field),  a  number  between  0  and  1;  otherwise, 
the  ORU  is  repaired. 

•  RANDOM  C#.  This  is  the  number  of  random  failures  before  an  ORU  is 
condemned.  A  value  of  “4”  signifies  that  on  the  fourth  random  failure  of  a 
particular  unit  of  the  ORU  (there  have  been  3  repairs),  jt  must  be 
condemned  regardless  of  the  value  of  RANDOM  cp  above.  A  value  of  “0”  (the 
default)  means  that  this  type  of  deterministic  condemnation  does  not  occur. 
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•  WEAR  cp.  This  is  the  probability  that  an  ORU  will  be  condemned  because  of 
wearing  out,  a  number  between  “0”  and  “1”;  otherwise,  the  ORU  is  repaired 
(MSPAREIN.RPT  fraction  3  field). 

•  WEAR  C#.  This  is  the  number  of  failures  attributable  to  wear  before  a 
condemnation,  similar  to  RANDOM  C#. 

•  Wgt.  The  weight  of  the  item  used  to  calculate  the  total  weight  per  period  for 
all  ORUs  to  replace  failures  in  orbit.  This  is  the  resupply  weight  needed 
over  and  above  the  initial  spares  requirement. 

•  CUMULATIVE  QPA  #  by  Month.  This  is  the  quantity  of  the  ORU  installed 
at  each  month.  This  should  be  nondecreasing  over  the  months.  (Note  the 
input  specifies  180  months  in  this  example,  and  the  model  develops  these 
data  elements  for  180  months,  not  just  the  10  shown  for  brevity  in 
Exhibit  10-2.)  Exhibit  10-2  data  is  the  QPA  profile  we  discussed  in  Chapter 
4.  In  this  example,  the  QPA  increases  to  18  in  month  13  for  ORU  1  and  to  36 
for  ORU  2. 

PROCESSING 

To  nm  the  simulation,  the  M-SPARE  interface  executes  the  preprocessor 
(PREPSIM.EXE)  to  prepare  PREPIN.DAT  data,  the  simulation  (PREP.EXE),  and 
the  plot  program  (PREPPLOT.EXE),  To  move  from  one  plot  to  the  next,  press  the 
“Enter”  key.  To  print  any  graph  on  the  screen,  type  anything  and  press  “Enter”. 
This  allows  you  to  type  labels  if  desired.  The  numeric  screen  output  is  written  to 
OUT.DAT,  and  data  input  for  M-SPARE  is  written  to  PREPOUT.DAT.  Again,  a 
math  co-processor  for  your  computer  is  not  required  but  is  highly  recommended,  as 
the  calculation  will  be  speeded  up  by  a  factor  of  about  10. 

OUTPUT 

The  numerical  output  for  this  example  is  shown  in  Exhibit  10-3.  If  the  input 
random  mean  is  much  smaller  than  the  wear  mean,  the  output  mean  would  equal  the 
random  mean.  The  VMR  would  equal  1  because  the  distribution  is  Poisson.  If  the 
wear  mean  is  much  smaller  than  the  random  mean,  the  output  mean  and  variance 
would  mimic  the  normal  or  Weibull  distribution  input  values.  With  the  sample  ORU, 
the  wear  and  random  means  are  comparable  (e.g.,  4  and  6  years),  so  the  output  mean 
is  less  than  both  (e.g.,  2.8  years)  and  the  VMR  is  less  than  1  (e.g.,  0.92). 
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Nutiibtr  of  months/period*  1 
BATTERY  ORU 

Fall  Time  Mean*  4.4966  Van*  1.0474 
MEAN  DEMAND  PER  PERIOD  INCLUDING  CONDEtWATIONS 
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0.04 
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0.06 

0.06 
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0.06 

0.06 

0.07 

0.06 

0.12 
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0.10 

0.10 

0.09 

0.10 
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0.10 

0.08 

0.12 

0.12 

0.12 

0.12 

0.13 

0.16 

0.17 

0.19 

4 

0.21 

0.22 

0.24 

0.29 

0.34 

0.38 

0.45 

0.56 

0.61 

0.71 

5 

0.74 

0.86 

0.95 

1.14 

1.17 

1.36 

1.41 

1.52 

1.52 

1.62 

6 

1.61 

1.57 

1.47 

1.43 

1.29 

1.22 

1.11 

1.09 

1.04 

0.93 

7 

0.87 

0.94 

0.90 

0.96 

0.99 

1.00 

1.03 

0.99 

1.02 

1.05 

8 

1.09 

1.07 

1.03 

1.05 

1.09 

1.04 

0.96 

0.89 

0.77 

0.69 

9 

0.57 

0.55 

0.41 

0.38 

0.39 

0.38 

0.35 

0.35 

0.41 

0.43 

10 

0.46 

0.50 

0.56 

0.60 

0.82 

0.69 

0.71 

0.78 

0.88 

0.87 

11 

0.98 

1.05 

1.04 

1.15 

1.07 

1.23 

1.18 

1.22 

1.21 

1.19 

VARIANCE/MEAN  DEMAND  PER 

PERIOD 
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1.04 
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1.06 

0.95 

1.07 

0.97 

0.96 

0.96 

1.00 

0.95 
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1.00 

1.02 

1.02 

1.01 

1.03 

1.00 

0.95 

0.95 

1.06 

0.97 

2 

0.94 

0.98 

1.03 

1.00 

1.04 

1.04 

0.99 

0.99 

1.01 

0.92 
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0.96 

0.94 

0.97 

0.95 

1.07 

1.09 

0.95 

1.03 

0.99 

1.03 

4 

0.97 

0.97 

0.97 

1.07 

0.89 

1.03 

0.91 

1.01 

0.95 

0.88 

5 

1.01 

0.90 

1.00 

0.89 

0.99 

0.93 

0.98 

0.92 

0.97 

0.91 

6 

0.92 

1.01 

0.96 

0.92 

1.01 

0.87 

1.03 

0.92 

0.94 

0.99 

7 

0.92 

0.91 

0.96 

1.01 

0.91 

1.02 

0.95 

0.92 

0.92 

0.97 

8 

0.98 

0.92 

0.91 

0.99 

0.91 

0.95 

0.89 

0.94 

0.94 

1.00 

9 

0.98 

0.97 

1.00 

0.97 

0.98 

0.97 

0.97 

0.98 

0.99 

1.12 

10 

1.05 

0.94 

0.96 

0.96 

1.00 

0.98 

0.98 

0.99 

0.92 

0.97 

11 

0.96 

1.02 

0.96 

0.99 

1.04 

0.97 

0.95 

1.03 

0.89 

0.91 

Period  Mean*  0.6158 

V/M* 

0.9600 

Aver  demand/unit* 

0.0130  Max  demand/unit 

•  0. 

0336 

Max  Period*  60 

CUMULATIVE 

AVERAGE 

:  CONDEMNATIONS  BY  PERIOD 
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0.05 

0.09 
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0.18 
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0.29 

0.33 

0.37 

0.41 

0.46 

1 

0.50 

0.56 

0.63 

0.69 

0.74 

0.80 

0.85 

0.92 

0.98 

1.04 

2 

1.11 

1.16 

1.24 

1.30 

1.42 

1.49 

1.59 

1.69 

1.78 

1.88 

3 

1.99 

2.07 

2.18 

2.30 

2.42 

2.54 

2.66 

2.82 

2.99 

3.18 

4 

3.40 

3.62 

3.86 

4.15 

4.49 

4.87 

5.32 

5.88 

6.49 

7.20 

5 

7.94 

8.80 

9.75 

10.89 

12.07 

13.42 

14.83 

16.35 

17.87 

19.49 

6 

21.09 

22.66 

24.13 

25.56 

26.85 

28.07 

29.18 

30.27 

31.30 

32.24 

7 

33.11 

34.04 

34.95 

35.90 

36.89 

37.89 

38.92 

39.91 

40.93 

41.98 

8 

43.07 

44.14 

45.17 

46.22 

47.32 

48.35 

49.32 

50.21 

50.98 

51.67 

9 

52.24 

52.79 

53.20 

53.58 

53.97 

54.35 

54.70 

55.06 

55.47 

55.89 

10 

56.35 

56.fc5 

liT  41 

58.01 

58.63 

59.31 

60.03 

60.81 

61.69 

62.56 

11 

63.53 

64.58 

6o  •  63 
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67.85 

69.08 

70.26 

71.49 

72.70 

73.89 

STANDARD  DEVIATION 

i  OF  CUMULATIVE 

:  CONOEIWATIONS  BY  PERIOD 
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0.22 

0.31 

0.38 

0.43 

0.49 

0.55 

0.59 

0.62 

0.66 

0.70 

1 

0.73 

0.77 

0.83 

0.88 

0.91 

0.95 

0.97 

1.01 

1.03 

1.05 

2 

1.08 

1.11 

1.14 

1.18 

1.23 

1.25 

1.30 

1.34 

1.38 

1.41 

3 

1.44 

1.46 

1.49 

1.52 

1.55 

1.59 

1.62 

1.61 

1.65 

1.70 

4 

1.76 

1.79 

1.86 

1.90 

1.94 

2.00 

2.13 

2.24 

2.33 

2.47 

5 

2.58 

2.65 

2.75 

2.79 

2.85 

2.94 

2.97 

3.00 

3.07 

3.01 

6 

2.98 

2.90 

2.79 

2.71 

2.66 

2.60 

2.50 

2.49 

2.44 

2.46 

7 

2.56 

2.57 

2.59 

2.56 

2.57 

2.64 

2.68 

2.74 

2.79 

2.76 

8 

2.77 

2.86 

2.84 

2.79 

2.73 

2.69 

2.60 

2.54 

2.42 

2.38 

9 

2.34 

2.30 

2.29 

2.29 

2.35 

2.39 

2.44 

2.53 

2.57 

2.65 

10 

2.72 

2.76 

2.81 

2.86 

2.93 

2.98 

3.04 

3.14 

3.23 

3.30 

11 

3.36 

3.42 

3.46 

3.48 

3.49 

3.47 

3.40 

3.41 

3.38 

3.39 

EXHIBIT  10-3.  OUTPUT  FOR  BATTERY  ORU 
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In  the  example,  the  battery  failures  are  dominated  by  wear-out.  That  is  the 
reason  that  the  mean  demand  —  including  condemnation  demand  —  has  large  peaks 
and  valleys,  and  why  the  VMR  per  period  is  substantially  less  than  1.  Whenever  the 
battery  wears  out  it  must  be  condemned.  This  accoimts  for  the  large  fluctuations  in 
annual  condemnations. 


Exhibit  10-3  also  shows  the  average  demand  per  unit  and  the  maximum 
demand  per  unit.  Though  not  displayed,  the  simulation  also  estimates  the  weight 
required  per  period  to  replace  repairable  failures  and  condemnations  on  orbit  for  all 
ORUs  that  have  been  processed. 

Exhibit  10-4  shows  the  failure  rate  plot,  m(t),  for  a  Battery  ORU  unit  that  is 
connected  to  the  probability  distribution  of  time  to  failure,  fit),  by  the  equation: 


mit)  — 


[Eq.  10-11 


where  F(t)\s  the  cumulative  distribution  of  the  probability  density,  /It)  from  0  to  t. 


I 


FAILURE  RATES 

BATTERY  ORU 


ORU  Age  in  Years 


EXHIBIT  10-4.  FAILURE  RATES 
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Exhibits  10-5  to  10-7  display  battery  OKU  plots  for  the  following: 

•  The  probability  distribution  of  time  to  failure  for  a  unit. 

•  The  mean  demand  per  year  for  all  units,  including  those  that  result  in 
condemnation. 

•  The  annual  condemnations  for  all  units  (not  the  cumulative  as  in  the 
numeric  output  above).  (The  first  peak  in  the  condemnation  plot  is  at  about 
5  years  -  near  the  wear-out  lifespan  of  the  battery.) 

Exhibit  10-8  shows  the  shuttle  weight  requirement  for  resupply  per  period  for 
all  wear-out  ORUs  to  replace  all  on-orbit  failures  of  any  type. 

UTILIZATION  OF  PREPROCESSOR  OUTPUT 

The  output  from  the  preprocessor  may  be  used  for  three  different  purposes; 
budget,  procurement,  and  shuttle  manifests.  Depending  on  the  purpose,  the  user 
may  want  to  separate  the  condemnation  output  from  the  repairable  demands 
(W/Con  =  0  in  the  input),  particularly  if  multiple  years  of  condemnations  are  bought 
at  one  time.  On  the  other  hand,  if  condemnations  are  replaced  by  orders  placed  at  the 
time  of  failure,  it  is  more  appropriate  to  combine  condemnation  demand  and 
repairable  demands  (W/Con=l).  This  is  the  assumption  M-SPARE  uses.  To  allow 
the  user  maximum  flexibility,  we  have  provided  the  capability  to  combine  the 
condemnation  and  repairable  demand  output  or  keep  them  separate. 

Integration  with  M-SPARE 

The  M-SPARE  model  uses  most  of  the  monthly  simulation  output  presented  in 
Exhibit  10-3  to  estimate  an  ORU’s  mean  on-orbit  failures,  mean  serviceable  (broken) 
spares,  replaced  condemnations,  and  the  VMR.  The  VMR  value  is  the  monthly  value 
at  the  launch  month.  [M-SPARE  does  not  use  the  simulation  VMR  if  the  user 
specifies  an  override  VMR  that  is  less  than  one  in  the  MSPAREIN.RPT  file  (see 
Preventive  Maintenance  discussion  in  Chapter  4).]  M-SPARE  also  calculates  other 
variables  at  the  launch  month  by  looking  back  to  determine  the  number  of 
unserviceables  and  replaced  condemnations.  It  also  looks  forward  to  determine  what 
fails  on  the  station  in  the  next  cycle.  The  formats  of  the  equations  are  similar  to  the 
formats  of  Equations  4-6  to  4-10,  except  instead  of  summing  monthly  QPA  values  the 
model  sums  the  appropriate  demand  values  from  the  simulation. 
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EXHIBIT  10-6.  DEMANDS  PER  MONTH 
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CONDEMNATIONS/MONTH 

BATTERY  ORU 


I 


i 


Vi 


a4^ 


Time  in  Years 


EXHIBIT  10<7.  CONDEMNATIONS  PER  MONTH 


EXHIBIT  10-8.  WEIGHT  PER  MONTH 
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The  four  key  demand  values  are  total  demand  (TD)  —  the  mean  demand 
subtable  in  Exhibit  10-3;  cumulative  condemnations  (CC)  —  the  third  subtable  in 
Exhibit  10-3;  condemnation  demands  (CD)  —  the  difference  in  successive-year 
values  of  the  cumulative  demands;  and  repair  demand  (RD)  —  the  difference  of  total 
minus  condemnation  demand.  Equations  10-2  to  10-8  estimate  mean  broken  spares, 
mean  orbit  failures,  and  replaced  condemnations. 

3 

MB(yr)  =$1  S/-  lEq.  10-2] 

/=i 

Ft  LMyrt- 1 

- L_X  ^  RLhm).  [Eq.  10-3) 


jp  LMiyr)  —  I 

Bi  ^  X  ^  RlXm). 
F1  +  F2  m  =  LM(yr)-AfM2 


LMlvr^  —  I 

B3  =  12  CD(m). 

m  =  LM(yr)  — 


LM(yr)  +MLC—  1 
MOiyr)  =  Y. 

m  =  LMiyr) 


CRCiyr)  = 


[ 


CC[yr)  -  Bsiyr) 


] 


[Eq.  10-4] 


[Eq.  10-5] 


[Eq.  10-6] 


[Eq.  10-7] 


RC(yr)  =  CRC(yr)  -  CRC(yr  -  1). 


(Eq.  10-8] 


where 

A  =  mean  orbit  failures  per  month 

m  =1,2,...  (year  X  12),  where  year  is  the  number  of  model  years  the 

user  specifies  (see  Chapter  6) 

I  —  maintenance  levels  ( 1  =  KSC,  2  =  prime/OEM,  3 = condemnations) 

F  —  fraction  of  total  failures  entering  each  maintenance  level 
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MM 

NLC 


[] 

MLC 


LM(yr) 

yr 

RC 

CRC 


=  maintenance  months  =  NLC  X  MLC 
=  number  of  logistics  cycles  in  the  entire  maintenance  time 


_  I  LogCycle  (days)-^  repair  or  replace  (days) 


"l 


LogCycle  (days) 


) 


=  largest  integer  value,  i.e.,  truncate  real  into  an  integer  value 

=  Months  in  a  LogCycle 

LogCycle  (days) 

30  (days!  month) 

=  launch  month,  calculation  point  of  spares  requirements,  assumes 
that  it  is  one  LogCycle  from  end  of  fiscal  year 

=  (yr  X  12)  -  MLC-1 

=  model  year 

=  replaced  condemnations 

=  cumulative  replaced  condemnations. 
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APPENDIX  A 


SPARES  OPTimZATION  PROOF 


The  Multiple  Spares  Prioritization  and  Availability  to  Resource  Evaluation 
(M-SPARE)  model  is  based  upon  a  marginal-analysis  approach.  Spares  are  ranked  in 
order  of  decreasing  benefit  per  cost  and  added,  in  that  order,  to  the  inventory  until  a 
target  resource  expenditure  or  station  availability  is  reached.  This  appendix  proves 
that  the  marginal-analysis  technique  generates  the  optimal  spares  solution;  that  is, 
no  spares  solution  set  produces  a  greater  availability  for  the  same  cost  or  produces 
equal  availability  for  less  cost.t 

From  Equation  3-1  of  the  main  text,  station  availability  is  defined  as 

A  -  station  availability  =W  PSN^  {«,  )  .  (Eq.  A-IJ 

I 

where  probability  of  a  spare  when  needed  (PSNO  (sj)  is  the  probability  that  a  spares 
level  of  Si  is  sufficient  for  ORUi  over  the  station  logistics  cycle,  i.e.,  that  the  number  of 
demands  over  the  cycle  is  less  than  or  equal  to  Si. 

We  want  to  maximize  Equation  A-1  subject  to  a  cost  constraint.  An  equivalent 
problem  is  to  maximize  the  logarithm  of  Equation  A-1  because  a  function  and  its 
logarithm  achieve  their  maximum  at  the  same  point.  Since  the  logarithm  of  a 
product  is  the  sum  of  the  logarithms,  this  converts  the  objective  function  into  an 
additive  separable  function  of  the  orbital  replaceable  unit  (ORU)  probabilities: 

ln(A)  =  Inistation  availability)  =  ^  In  [  PSN^i ». )  ] ,  [Eq.  A-21 


^Further  discussion  of  these  and  related  issues  can  be  found  in  LMI  Report  AF201,  The  Aircraft 
Availability  Model:  Conceptual  Framework  and  Mathematics,  T.  J.  O’Malley,  June  1983  and 
Craig  C.  Sherbrooke,  Optimal  Inventory  Modeling  of  Systems:  Multi-Echelon  Techniques,  New  York: 
Wiley,  to  be  published  in  September  1992. 
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Denote  the  benefit  per  cost  ratio  of  buying  the  nth  spare  of  ORUi  by  r(i,n).  Then, 


Ki.ra)  =  PSN,\n)  ~  In  PSNiin  - 1 ) 

- - - ’  (Eq.A-31 

where  Ci  is  the  cost  of  ORUi.  We  will  sometimes  simply  refer  to  r(s)  when  the  exact 
values  of  i  and  n  are  immaterial.  The  marginal  analysis  algorithm  in  M-SPARE 
sorts  the  ORU  spares  in  terms  of  r(i,n),  which  we  will  call  the  sort  value.  We  wish  to 
show  that  buying  in  this  order  is  optimal. 

We  first  note  that  for  this  procedure  to  even  make  sense,  In  PSN  must  be 
convex,  i.e.,  r  must  be  a  decreasing  function  of  spares  level  for  each  ORUi;  otherwise, 
one  could  be  led  to  the  meaningless  situation  of,  say,  wanting  to  buy  the  third  spare  of 
an  ORU  before  buying  the  first  spare.  This  is  physically  nothing  more  than  the  law  of 
diminishing  returns  for  spares  —  each  additional  spare  is  worth  less  than  (or  equal 
to)  the  one  preceding  it. 

We  will  show  that  r  is  decreasing  in  the  case  of  a  Poisson  failure  process.  The 
same  approach  can  be  used  in  the  case  where  failures  are  distributed  according  to  the 
binomial  or  negative  binomial  distribution. 

Let 


[Eq.  A-41 


represent  the  (Poisson)  probability  of  jc  unserviceable  items  in  resupply  and  where  X 
represents  the  mean  number  of  unserviceables  in  resupply.  Then 

PSN(8)  =  p(x).  [Eq.  A-5] 

1=0 


It  is  enough  to  show  that,  for  all  s, 


In  PSN(s)-  In  PSN(a  -l)>ln  PSN(8+ 1)-  In  PSNfs) 


[Eq.  A-61 


Equation  A-6  is  equivalent  to 


In 


g  =  0 

,  E  PM 

\  x=0 


^  In 


( »+i  \ 

E 

1=0 

E  prx; 

\.=0  J 


*  S  +  l 

£  p(x)  E 


E  p^*^ 

E  prx) 

x=0 

x=0 

l+p(s) 

l+p(8+l) 

t-l  2  s 

E  p(*> 

E 

*=0 

X  =  0 

p(s) 

p(«  +  l) 

Substituting  p(*)  = 


E!  E 

*=0  *=0 

* 

p(«)E  p(*)^p(»+i)E 

*=o  *=o 


A""! 

—  I®  in  the  above  yields, 


V  ^-x  ^  ^  ^-x  ^  ^-x  V  £g-x 


lEq.  A-7] 


[Eq.  A-81 


lEq.  A-91 


[Eq.A-101 


(Eq.A-111 


»!  x=0  x\ 


(«+!)!  *=o  x! 


lEq.  A-121 
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[Eq.A-13] 


z=o  s!x! 


s—  l 


1=0 


(s  +  l)!i! 


*-l  \s+z+l 

+  E  =•  E 

1=0  s!(i+l)'.  1=0 

(s  +  l)!x! 

[Eq.  A-141 


Since  x+1  s  s  +  1,  each  of  the  terms  in  the  left-hand  summation  exceeds  the 
corresponding  term  in  the  right-hand  summation.  Thus,  the  inequality  holds,  PSN  is 
convex,  and  the  sort  value  is  indeed  a  decreasing  function  of  spares  level. 

If  M  is  any  set  of  spares,  we  vdll  denote  by  M(i)  the  number  of  spares  of  ORUii) 
in  the  set  Af,  by  A(M)  the  resulting  station  availability,  and  by  C{M)  the  cost  of 
procuring  the  spares  in  M.  We  have: 


Am)  =  IlpsiVj[  ^0')+i  ] 
i 

cm)^YL 


[Eq.  A-15] 


tEq.A-16] 


where  Cj  is  the  cost  of  ORUi. 

If  we  increase  the  level  of  ORUj  from  M{j)  to  M{j)  + 1  to  form  a  new  spare  set  Af  '» 

then 


In  Am)  =  ^  lnPSNi[  M{i)  ]  +  InPSNjl  +  [Eq.  A-17] 

i*j 

=  InPSNi  [  M(i)  I  +  InPSNjl  Af’O'l  +  l  ]  -/nPSAi}[  ^U)  1 
i 

=  lnA{M)+  cy r[ XMOl  +  l  ]. 

That  is,  adding  a  spare  s  with  cost  c(s)  to  the  set  M  gives  a  new  availability  AiM'), 
with  In  AiM')  —  In  A(Af)  +  c(s)  Ks), 


In  general,  adding  any  number  of  spares  to  Af  to  form  M'  results  in  a  new 
availability  and  the  similar  relationships 

lnA{M’)  =  lnA(Af)+  c(s)r<«),  rgq  A-18] 

aiM'-M 

where  M'  —  M  denotes  the  difference  of  the  sets  M'  and  M,  the  collection  of  spares  that 
were  added. 

Now  suppose  that  the  set  Af  was  obtained  via  marginal  analysis,  and  let  N  be 
any  other  set  of  spares  with  lower  or  equal  total  cost,  C(N)  s  C(Af).  To  show  Af  is 
optimal,  we  must  show  that  A(N)  s  A(Af)  or,  equivalently.  In  A(N)  s  In  A{M). 

Let  X  =  iV^Af,  the  intersection  of  iVand  Af.  Then  X  contains  the  spares  common 
to  both  sets  Af  and  N.  By  the  above,  we  have 

lnA{M)  —  InAiX)  +  [Ea  A-191 

stM-X 


InAiN)  ~  lnA(X)  +  ^  c(8)r(a).  rgq  A-201 

s^N-X 

The  marginal-analysis  technique  dictates  that  Af  contains  all  of  the  highest  sort 
values.  Therefore,  since  M—X  and  N—X  are  disjoint,  we  know  that  the  lowest  sort 
value  r(M)  of  spares  in  Af  —  X  is  greater  than  the  greatest  sort  value  r(N)oi  a  spare  in 
N~X.  Further,  since  C(M)  s  C(N),  C(M-X)  a  C(N-X).  Thus, 

lnA(M)  =  lnAiX)+  ^  cfaMs)  [Eq  A-21] 

am-X 

2  inArxH  m)  IZ 
8€M-X 

a  //iA(X)+  KM)  C(M-X) 

>  lnA(X)-^r(N)C(N-X) 

2  InAiXH  HN)  5Z 

a^N-X 

2  lnA(X)+  ^  cfaHs) 
a^N-X 


=  InA(N). 


Thus,  M  is  an  undominated  set  of  spares,  and  the  optimality  of  marginal 
analysis  is  proved. 
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APPENDIX  B 


REPAIR  BUDGET:  METHODS,  ASSUMPTIONS,  AND  DATA 


The  M-SPARE  repair  budget  estimates  center  around  a  single  ratio:  an  orbital 
replaceable  unit’s  (ORU’s)  repair-to-procurement-cost  ratio.  M-SPARE  multiplies 
that  ratio  by  the  ORU’s  procurement  cost  to  obtain  the  ORU’s  repair  cost.  It  then 
multiplies  the  repair  cost  by  the  annual  number  of  ORU  repair  actions  (total  failures 
minus  condemnations)  to  obtain  the  annual  repair  budgets.  The  model  uses  that 
simple  ratio  because  more  detailed  repair  data  for  the  station  are  not  yet  available. 
After  examining  available  repair  data  from  existing  NASA  systems,  we  decided  that 
use  of  the  repair  ratio  was  the  best  means  for  estimating  repair  budgets: 

•  The  ratio  puts  realistic  bounds  on  the  problem.  A  large  ratio  (e.g.,  85  to 
100  percent)  is  not  practical  because  if  the  ORU  repair  costs  that  much, 
procuring  a  new  ORU  would  be  the  better  course  of  action. 

•  The  ratio  is  sensitive  to  the  procurement  cost  of  the  ORU;  more  expensive 
ORUs  cost  more  to  repair. 

•  The  ratio  method  is  based  upon  historical  NASA  data. 

In  this  appendix,  we  describe  how  and  why  we  determined  the  M-SPARE 
default  repair  ratio  of  28  percent.  First,  we  present  the  historical  NASA  data  from 
the  Spacelab  (a  laboratory  that  flies  in  the  shuttle  bay)  and  NASA’s  Orbiters  (i.e.,  the 
shuttles).  We  then  show  how  we  calculated  the  ratio  and  how  a  single  ratio  seems  to 
represent  a  good  indicator  of  repair  costs  across  components  even  when  procurement 
cost  varies  dramatically. 

REPAIR  DATA 

Table  B-1  presents  the  original  equipment  manufacturer’s  (OEM’s)  repair  data 
for  the  Spacelab  and  the  shuttle  divided  into  three  basic  categories:  direct  labor  costs 
(proportional  to  the  niunber  of  ORUs  repaired),  fixed  labor  costs  (an  annual  OEM  fee 
independent  of  the  number  of  ORUs  repaired),  and  material  costs.  Those  data  are 
taken  from  readily  available  sources  or  are  general  estimates  of  NASA  experts  and 
are  not  the  result  of  an  extensive  data  search.  We  used  only  OEM  repair  data  since  it 
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is  not  known  whether  a  Kennedy  Space  Center  (KSC)  NASA  depot  will  perform 
station  repair. 


TABLE  B-1 

COMPARING  SPACELAB  AND  SHUTTLE  REPAIR  COSTS 


Cost  component 

FY93($000) 

Percent  of  budget 

Spacelab* 

Shuttle^ 

Spacelab* 

Shuttle^ 

Labor  (direct) 

2,175 

26,800 

78 

49 

Labor  (fixed) 

524 

18,300 

18 

33 

Material 

100c 

10.000c 

4 

18 

Sum 

2.799 

55.100 

100 

100 

No.  ORU/LRU  repaired 

24 

524 

$000/repair  FY93 

117 

105 

$000/repair  FY92 

112 

100 

Mot*;  LRU  •  lin«  replaceabi*  unit. 

*  Spacelab  information  from  seven  OEMs. 
^Shuttle  OEM  information  <FY93). 

<  Rough  estimates  from  telephone  conversations. 


For  the  Spacelab,  the  information  csune  from  a  sample  of  seven  U.S.  OEM 
depots  (see  Table  B-2).  The  **total’’  line  in  Table  B-2  specifies  the  data  used  in 
Table  B-1  for  all  the  OEMs.  The  direct  labor  cost  of  $2,175,000  in  Table  B-2  equals 
the  average  repsur  cost  times  the  number  of  ORUs  repsured  at  each  OEM.  The  fixed 
labor  cost  in  Table  B-2  is  the  retention  cost  for  management  of  bonded  storage, 
maintenance  of  technical  documentation  and  test  equipment,  Emd  program 
management  ($524,000).  Material  cost  includes  parts  used  in  the  repair  actions 
($100,000).  The  number  of  ORUs  repaired  for  the  yesu:  was  24. 

For  the  shuttle,  the  information  came  from  the  estimated  repair  requirements 
for  FY93,  which  are  closely  linked  to  historical  information.  The  direct  labor  costs 
£u*e  the  estimated  OEM  costs  and  do  not  include  the  NASA  depot  or  Downey  facility. 
The  fixed  labor  cost  equals  the  smnual  subcontracting  agreements  from  some 
77  OEMs  (NASA  terms  those  costs  ”Phase  A”  costs)  plus  the  capability  retention 
costs  for  OEMs  no  longer  making  shuttle  components  (those  costs  ensure  that  the 
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TABLE  B>2 


KSC  SPACELAB  FUGHT  HARDWARE  -  U.S.  DEPOT  COSTS 


U.S.  depot/vendor 

Retention 

costs 

(FY93  $000)> 
(firm) 

Unit 

repair  costs 
(FY93  $000)b 
(estimate) 

FY92 

repaired 

Direct  costs 
(costs  X  repaired) 

Ai  research 

30.0 

40.0 

2 

80 

Brunswick 

131.0 

30.0 

1 

30 

Carleton 

153.0 

30.0 

0 

0 

Hamilton  standard 

23.0 

90.0 

6 

540 

ODETICS 

127.0 

157.0 

4 

628 

96.0 

7 

672 

Honeywell 

24.0 

67.5 

2 

135 

IBM-OWEGO 

35.5 

45.0 

2 

90 

Total 

Average  cost 

523.5 

74.8 

555.5 

69.4 

24 

2,175 

90.6 

•  Depot  retention  costs  include  management  of  bonded  storage,  maintenance  of  technical  documentation  and  test 
equipment,  and  program  management. 


»  Unit  repair  costs  do  not  include  parts  used  in  the  repair.  Estimate  the  seven  U.S.  depots  consume  a  total  of  $100,000  per 
year. 


OEM  retains  the  skilled  labor  necessary  to  repair  components,  and  NASA  terms 
them  "Phase  B”  costs).  Two-thirds  of  the  shuttle  fixed  labor  costs  fall  into  the  Phase 
B  category.  The  total  LRUs  repaired  equal  the  sum  of  reparable  and  nonreparable 
LRU  parts  rework  replacements  (PRR). 

The  two  NASA  systems  show  very  different  breakouts  of  the  three  budget 
categories  as  a  percentage  of  the  total  budget  (see  Table  B-1).  That  is  not  surprising 
since  the  two  NASA  systems  are  very  different  in  function,  number  of  systems,  types 
of  repair  capability,  and  accounting  methods.  For  instance,  the  shuttle  is  a  launch 
vehicle,  and  its  engines  require  more  material-intensive  repEur  than  a  laboratory. 
Also,  since  the  shuttle  is  shifting  most  of  its  repair  capability  to  the  NASA  facility  at 
KSC  and  thus  decreasing  its  direct  costs,  fixed  retention  costs  for  the  OEM  go  up. 
Even  with  those  differences,  for  FY93  the  Spacelab  and  the  shuttle  average  repair 
costs  per  component  (ORU  or  LRU)  are  very  similar  at  $117,000  and  $105,000, 
respectively.  Consequently,  we  decided  to  move  away  from  estimating  the  three 
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repair  categories  since  they  varied  so  and  instead  use  the  average  repair  cost  that  is 
more  consistent  between  the  NASA  systems. 

We  initially  used  that  average  repair  cost  per  component  times  the  number  of 
repairs  to  produce  repair  budgets;  however,  that  method  resulted  in  inconsistent 
repair  budgets  for  certain  groups  of  station  ORUs.  For  instance,  sometimes  the 
model  operates  on  relatively  inexpensive  ORUs,  and  the  use  of  a  straight  repair  cost 
created  budgets  close  to  the  cost  of  procuring  new  ORUs  for  every  repair  action. 
Thus,  we  needed  a  repair  cost  estimator  sensitive  to  ORU  procurement  costs  yet  still 
capable  of  keeping  the  average  ORU  repair  cost  around  $100,000.  That  estimator  is 
the  repair  ratio. 

THE  REPAIR-TO-PROCUREMENT  RATIO 

The  repair-to-procurement  ratio  is  the  average  repair  cost  divided  by  the 
average  procurement  cost.  NASA  estimates  the  procurement  cost  for  Spacelab  ORUs 
is  between  $300,000  and  $500,000.  (NASA  shuttle  did  not  have  an  analogous 
procurement  cost  for  the  repaired  OEM  LRUs.)  We  next  estimated  the  station  ORU 
procurement  costs,  which  are  very  comparable  to  the  Spacelab  costs.  The  station 
average  procurement  cost  is  about  $400,000  (FY92)  when  weighted  by  the  ORU’s 
estimated  number  of  repairs  in  FY02.  The  station  procurement  cost  used 
preliminary  station  data  across  work  packages.  By  dividing  the  average  Spacelab 
repair  cost  ($112,000  in  FY92)  by  an  appropriate  average  procurement  cost  ($400,000 
in  FY92),  we  produce  the  M>SPARE  default  repair  ratio  of  28  percent. 

The  final  M-SPARE  default  value  we  needed  to  estimate  was  the  labor 
percentage.  The  labor  percentage  splits  the  annual  repair  budget  into  repair  cost 
estimates  for  labor  and  for  material.  The  model  multiplies  the  total  repair  cost  by  the 
labor  percentage  to  estimate  the  labor  component  and  by  one  minus  the  labor 
percentage  to  estimate  the  material  component.  We  estimated  the  default  value  by 
taking  the  average  of  the  labor  percentages  (fixed  and  direct)  for  Spacelab  and  the 
Shuttle  —  roughly  90  percent.  Thus,  M-SPARE  uses  the  28  percent  repair  ratio  and 
90  percent  labor  costs  as  its  default  values  (see  Chapter  6  to  set  those  options). 

HOW  GOOD  IS  A  SINGLE  REPAIR  RATIO? 

Now  that  we  have  a  repair  ratio,  the  next  step  is  to  determine  how  well  it 
indicates  repair  costs  across  all  ORUs.  Since  NASA  could  not  easily  access  the  repair 
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and  the  procurement  cost  at  a  component  level,  we  used  data  from  the  U.S.  Air  Force. 
We  examined  B1  bomber  data  because  some  of  that  system’s  LRUs  are  comparable  in 
cost  to  NASA’s  expensive  components.  Table  B-3  displays  the  repair  ratio  (the  sum  of 
the  unit  repairs  divided  by  the  sum  of  the  procurement  costs)  for  three  LRU  subsets. 
If  we  examine  all  LRUs,  the  average  procurement  cost  is  $49,000  and  the  repair  ratio 
is  11.6  percent.  If  we  examine  only  LRUs  that  cost  more  than  $20,000,  the  average 
procurement  cost  increases,  but  the  repair  ratio  stays  basically  the  same.  Even  when 
we  examine  only  the  most  expensive  ORUs  with  an  average  cost  of  $313,000,  the 
repair  ratio  remains  at  11  percent.  This  analysis  indicates  that  though  the 
procurement  costs  of  components  may  change,  the  repair  ratio  on  average  stays  fairly 
constant. 


TABLE  B-3 

STRONG  CORRELATION  BETWEEN  UNIT  REPAIR  AND  PROCUREMENT  COSTS 

(Example:  B1  bomber) 


Subsets  of  B1  LRUs  by 
procurement  cost 

Average 

procurement  costs 
($000) 

Approximate 
ratio  of  unit  repair 
to  procurement  costs 
(%) 

All  LRUs 

49 

11.6 

LRUs  greater  than  $20,000 

150 

11.1 

LRUs  greater  than  $  1 00,000 

313 

11.1 

Air  Force  rule  of  thumb 

10  -  20 

CONCLUSION 

Estimating  aggregate  dollar  repair  requirements  by  using  a  single  ratio  across 
all  ORUs  seems  appropriate  until  more  detailed  data  become  available.  The  ratio  is 
sensitive  to  an  ORU’s  procurement  price,  it  allows  the  user  to  place  bounds  on  repair 
cost,  and  it  uses  actual  NASA  data.  A  possible  future  enhancement  to  that 
methodology  may  include  a  ratio  based  upon  the  type  of  ORU  (mechanical  or 
electrical),  a  ratio  that  varies  over  time  to  reflect  the  transition  from  OEM  to  a 
centralized  KSC  depot,  and  a  separate  estimate  for  shop  replaceable  units  and 
material  costs. 
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GLOSSARY 


Ascn 

= 

American  Standard  Code  for  Information  Interchange 

CAGE 

— 

Commercial  and  Government  Entity 

CRC 

= 

cumulative  replaced  condemnations 

DOS 

= 

Disk  Operating  System 

EPS 

= 

electric  power  system 

FSCM 

=z 

Federal  Supplier  Code  for  Manufacturers 

IBM 

= 

International  Business  Machines 

KSC 

= 

Kennedy  Space  Center 

LC 

= 

LogCycle 

LM 

= 

launch  month 

LMI 

= 

Logistics  Management  Institute 

LRU 

= 

line  replaceable  unit 

MB 

= 

mean  broken 

MO 

= 

Mean  number  of  Orbit  failures  for  the  next  logistics  cycle 

M-SPARE 

= 

Multiple  Spares  Prioritization  and  Availability  to  Resource 
Evaluation 

MTBF 

= 

mean  time  between  failures 

NASA 

= 

National  Aeronautics  and  Space  Administration 

OEM 

= 

original  equipment  manufacturer 

ORU 

= 

orbital  replaceable  unit 

PC 

= 

personal  computer 

PLT 

= 

procurement  lead  time 

POP 

= 

Program  Operating  Plan 

POS 

= 

probability-of-sufficiency 
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PRR 

= 

parts  rework  replacements 

PSN 

= 

probability  of  a  spare  when  needed 

QPA 

= 

quantity  per  application 

RAM 

= 

random  access  memory 

RMAT 

= 

Reliability  and  Maintainability  Assessment  Tool 

SIMSYLS 

= 

simulation  of  manned  space  station  logistics  support 

SRU 

= 

shop  replaceable  unit 

SSF 

= 

Space  Station  Freedom 

VMR 

variance-to-mean  ratio 
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